forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Difference between release and checkmate?
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
FK_GER



Joined: 26 Oct 2017
Posts: 29
Location: University of Kassel,Germany

PostPosted: Wed Oct 31, 2018 9:11 pm    Post subject: Difference between release and checkmate? Reply with quote

I've compiled and linked my program as release-version and as checkmate-version, both with standard settings.
I'm astonished, that the results of these two versions are slightly different.
Why that? The same fortran-sources and the same example!
Has anybody an explanation?
I'm using personal edition 8.3
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1004

PostPosted: Wed Oct 31, 2018 9:52 pm    Post subject: Reply with quote

If your program uses REAL variables, and performs some nontrivial computations, such slight differences are not unusual.

If you showed the test code, some more specific explanations may become possible.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5542
Location: Salford, UK

PostPosted: Thu Nov 01, 2018 8:45 am    Post subject: Reply with quote

The order in which the calculations are performed and the use of registers can be different. This means that round-off error can change. In extreme cases, round-off error can seriously affect the results.

If you are using single precision REALs then try using /DREAL on the command line. If you are using double precision REALs with Win32 then try using /XREAL on the command line. This will indicate the extent of round-off error.
Back to top
View user's profile Send private message
FK_GER



Joined: 26 Oct 2017
Posts: 29
Location: University of Kassel,Germany

PostPosted: Thu Nov 01, 2018 6:06 pm    Post subject: Reply with quote

I've expected these or similar explanations , you have done. But this effect must be a peculiarity of the used FTN95.
My programs also run under XP with an Compaq Compiler (Visual Fortran 6.6). And there, the results of the release version and the check version are identically. Therefore I'm astonished about the results of FTN95.
Even though the results of FTN95 are slightly different at some intermediate data, the final result is not affected fortunately.
To show the whole source code of my program is not constructively. The program consists of more than 70 subroutines. It's expensively to search the places, where the differences happens.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5542
Location: Salford, UK

PostPosted: Thu Nov 01, 2018 7:43 pm    Post subject: Reply with quote

I am not surprised that /CHECK results are slightly different from "release" results. For Win32 in particular, FTN95 is able to do many of the calculations using 80 bit precision but the scope for doing this is significantly reduced in /CHECK mode. Hence you might get a slightly "poorer" result in /CHECK mode.

You also assume that Compaq CHECK mode is similar to that in FTN95 and it may be much more limited.

In general REAL results are invariably subject to round-off error and the results will vary slightly from one compiler to another and usually between check/release modes. The fact that Compaq results are the same for check and release may be because not much is checked.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1004

PostPosted: Fri Nov 02, 2018 12:10 am    Post subject: Reply with quote

If the program in question has some variables that are used without proper initialisation, you may see different results in repeated runs even without any change in the compiler options. Compaq Fortran, by default, gave all variables the implicit attribute SAVE. Most current compilers, including FTN95, do not.

Therefore, what you are seeing as a deficiency in the compiler may be actually a good hint of the existence of unsuspected bugs in your program -- use either the /undef or the /checkmate option of FTN95 and hunt these bugs down!
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 927
Location: Aerospace Valley

PostPosted: Sat Nov 10, 2018 12:26 am    Post subject: Reply with quote

FK_GER, you wrote:
Quote:
I'm astonished, that the results of these two versions are slightly different.

Well, it depends on what magnitude these 'results' are of course.

Maybe you could give a couple of examples of the different values you've seen ? u said is ok.And the magnitude of the 'final result',which you say is fortunately ok.

If the values are different they might actually be the same !!!



[/quote]
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
FK_GER



Joined: 26 Oct 2017
Posts: 29
Location: University of Kassel,Germany

PostPosted: Thu Nov 15, 2018 11:34 am    Post subject: Reply with quote

Here an example, to show what I means. The picture is an screen-shot of a program, which compares two result-files, one generated with the check-program (right), the other with the release-version (left). Presented is the page with the final result. The differences are red coloured and are clearly, but not significantly (M_Rd/M_Ed,res is the same).

Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5542
Location: Salford, UK

PostPosted: Thu Nov 15, 2018 12:13 pm    Post subject: Reply with quote

Are you using single precision REALs or DOUBLE PRECISION?
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1994
Location: Sydney

PostPosted: Thu Nov 15, 2018 12:48 pm    Post subject: Reply with quote

With the check program, why don't you use SDBG and see where these calculations are taking place.

Examples such as:
"Formelzahler : Z1 = 177.5959" vs "Formelzahler : Z1 = 178.3901"
These look to be significantly different, and probably not due to round-off
I would expect that there are uninitialised variables.

You should use the /undef option, rather than /check, then use SDBG
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1004

PostPosted: Thu Nov 15, 2018 1:17 pm    Post subject: Reply with quote

Compaq Fortran does not emit SSE2 code; only X87 instructions are used for floating point arithmetic. If FTN95 was used only to generate 32-bit code in both check and release modes, the resulting program also uses only X87. If, furthermore, as I suspect, the calculation is for a linear elastic stress analysis, my guess is that the differences are far higher than expected, unless there is some geometric nonlinearity involved. For a reinforced concrete structure, I (not being a structural engineer) do not expect such geometric nonlinearity.

A specific question: do the results from CVF agree better with either of the FTN95 results?

A couple of comments: I think that the differences need to be investigated and either resolved or explained. Do the differences surface for a number of different test problems, or are you reporting a special case where the differences became noticeable for the first time?

If the source code cannot be shared, FK_GER will have to resolve the issues without much help from forum readers. Perhaps, the code can be shared with Silverfrost personnel?
Back to top
View user's profile Send private message
FK_GER



Joined: 26 Oct 2017
Posts: 29
Location: University of Kassel,Germany

PostPosted: Thu Nov 15, 2018 2:11 pm    Post subject: Reply with quote

Thanks for the various hints.
In the next days I'll try to follow them.
First of all I'm using in the program single precision REALS generally as well as double precision reals in some subroutines, where a higher precision is necessary because of special iteration processes for equilibrium of stresses and of forces.
What is SDBG? Debugging?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1004

PostPosted: Thu Nov 15, 2018 2:53 pm    Post subject: Reply with quote

SDBG is the Silverfrost symbolic debugger, and it may be used either by itself or from the Plato Editor/IDE. I have found it to be a well-designed, efficient tool for debugging programs compiled using FTN95. A particularly nice feature is that when an error occurs, it gives you the ability to trace the calls up the stack and examine the values of variables in the sequence of the calling subprograms.

The design of the X87 FPU is such that there is not much saved or lost by using single-precision arithmetic. Most of the arithmetic operations are done in the FPU registers ST0 to ST7, which are 80 bits long. If you use /DREAL, you will be able to see whether going to full double-precision is worthwhile, without changing the source code much, if at all.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5542
Location: Salford, UK

PostPosted: Thu Nov 15, 2018 4:32 pm    Post subject: Reply with quote

If you are producing a 32 bit Win32 executable then (paradoxically) you can put /XREAL on the command line in order to get universal extended precision (80 bit reals). Using /DREAL in one test and then /XREAL on another would provide a simple test of the potential effect of round-off error on your results.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1854
Location: Yateley, Hants, UK

PostPosted: Thu Nov 15, 2018 10:13 pm    Post subject: Reply with quote

Mecej4,

Isn't it true that the precision is lost when transferring a value from the 8087 register to a location in RAM, especially if the latter is a 32-bit REAL*4 entity? (and less, but still some, if the target is REAL*8?) This is more likely to be the cause of a difference in precision than roundoff inside the x87 fpu. Check mode can't allow the same use of registers that release mode does, as the latter would appear to be doing some (benign?) register optimization.

Paul, I had forgotton /XREAL. How do we (bearing in mind another post on needing ...D.. for DREAL constants) declare constants to be XREAL?

Eddie
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group