- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page