forums.silverfrost.com

[FK_GER]

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

[mecej4]

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.

[PaulLaidler]

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.

[FK_GER]

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.

[PaulLaidler]

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.

[mecej4]

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!

[FK_GER]

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).

[PaulLaidler]

Are you using single precision REALs or DOUBLE PRECISION?

[JohnCampbell]

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

[mecej4]

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?

[FK_GER]

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?

[mecej4]

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.

[PaulLaidler]

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.

[LitusSaxonicum]

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

[PaulLaidler]

Eddie

In answer to your question, one way is to write 1.0_3 or 1.0_k where k has been set a call to SELECTED_REAL_KIND.

But if /XREAL is like /DREAL then you will get the extra precision in the constant without adding the kind specifier.