Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28535 Discussions

ERFC returns different values from Fortran 2020.4.311 and 2024.1

Greenhills
Beginner
409 Views

I'm trying to convert my program from 2020.4.311 to 2024.1 and I'm getting pretty consistent results except for the erfc() function call when a small value, 4.338867E-03, is assigned to the variable sampleZ in the following equation.  The old version returns 0.4982690 for LOLP and the new version returns 0.4982691.   This causes significant differences in simulation results at the end.

 

LOLP = 1.0 - erfc(-sampleZ / sqrt(2.0)) * 0.5

 

Here are the compiling options

/nologo /debug:minimal /O2 /Qparallel /assume:buffered_io /Qip /recursive /fpscomp:filesfromcmd /fpscomp:ioformat /fpscomp:logicals /fpscomp:general /warn:interfaces /Qsave /fp:source /module:"x64\Release\\" /object:"x64\Release\\" /Fd"x64\Release\vc160.pdb" /traceback /check:bounds /libs:static /threads /winapp /Qmkl:parallel /c

 

Linker:

/OUT:"x64\Release\hpcon.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST:NO /SUBSYSTEM:CONSOLE /STACK:200000000 /IMPLIB:"H:\LCGSRC\IntelFortran\Hpcon_Trunk\x64\Release\hpcon.lib"

 

The program includes IMSL libraries as shown in the screenshot below,

 

Greenhills_0-1712183461884.png

 

Also, I wrote a 10-line program with the erfc() function call and passed the same small value, 4.338867E-03, using the new compiler I got back to expected value, .4982690.

 

Let me know if you need any further information.

 

Thanks,

Greenhills

0 Kudos
1 Solution
mecej4
Honored Contributor III
362 Views

According to Wofram Alpha , the correct mathematical value is 0.4982690479357465109374316515219356231746675552899123280143 . Thus, your old value is not much better than the new value in accuracy. At any rate, single precision is not sufficient here; if you need more accuracy, you have to investigate whether to promote all real variables to double precision, or promote a carefully selected subset of the variables.

View solution in original post

0 Kudos
3 Replies
Arjen_Markus
Honored Contributor I
377 Views

If your simulation is so sensitive to the exact results - you are on the verge of machine precision with this, then you should probably use double precision instead or seek a different algorithm. Such differences could also occur with different compile options (optimisation notably).  As I do not know what your simulation entails, I can only make a general suggestion like this, but it seems to me to be quite delicate as it is.

0 Kudos
mecej4
Honored Contributor III
363 Views

According to Wofram Alpha , the correct mathematical value is 0.4982690479357465109374316515219356231746675552899123280143 . Thus, your old value is not much better than the new value in accuracy. At any rate, single precision is not sufficient here; if you need more accuracy, you have to investigate whether to promote all real variables to double precision, or promote a carefully selected subset of the variables.

0 Kudos
Greenhills
Beginner
331 Views

Thank you, Arjen and mecej4.  I did a few more tests.  It seems that the old version is less accurate as mecej4 mentioned.  For the 10-line program, if the floating point model is set to "fast" in ifort mode, the function would return the same value as the old version, if it is set to "source" or "strict", it'd return the same value as the new version.  In the ifx mode, all options return the same value,  .4982691.

 

Now, I feel more comfortable with the new version.    Thanks again.

Reply