[mesa-users] inconsistent READs for ifort vs gfortran

Francis Timmes fxt44 at mac.com
Tue Dec 24 22:19:18 EST 2013

yes. i've known of this for a long time.

one of the tests done during creation of the helm table is to
open the file, write the values, close the file, open the file,
read the values, close the file and compare the read values
with the values still in memory. there is flutter in the last digit
for some/most values. 

it was unclear to me if the difference between what's in memory was 
caused by the write statement or by the read statement. once i tried 
reading and writing in quad precision but the truncation/roundoff to 
the double precision variables seemed to introduce its own flutter 
in the last digit for a different set of some/most values.

at the time, i found this flutter present using the xlf, ifort, g95, 
gfortran, and absoft compilers. each compiler would find its own 
mostly unique set of values where the flutter would occur.

at that point i moved onwards because i do not know how to control
either the write/read or the truncation/roundoff from higher precision values
to the 16th decimal point beyond the language supplied standard statements.


On Dec 24, 2013, at 8:00 PM, Bill Paxton <paxton at kitp.ucsb.edu> wrote:

> I'm hoping someone can help me with this one.
> About 1/2 of the mesa/star test cases are now getting the same results with ifort 14 as with gfortran.  Today I was working on one of the remaining bad ones -- hb_2m.   Eventually I tracked the source of the difference to the eos.  Turns out that when reading the helm_table.dat text file, there are over 100 cases where gfortran and ifort both read incorrect values.  The strange thing is that when gfortran and ifort disagree, neither one has the value that is given in the file!  Here's an example.
> 9.3921038971518730D+15		in source file (line 424)
> 9.3921038971518720D+15		gfortran gives this
> 9.3921038971518740D+15		ifort gives this
> To check, I wrote out all the values read from the file and compared.  The source file for reading is mesa/data/eosDT_data/helm_table.dat    Here's the diff file for output from ifort and gfortran.
> <diff>
> (BTW: I have not tested for cases where ifort and gfortran get the same value, but it is not the value in the source file.)
> The helm_table.dat file is read by the routine read_helm_table in eos/private/helm_alloc.f
> Here's my edited version that writes out what it reads for checking.
> <helm_alloc.f>
> I'm testing this with version 5766.
> Any ideas welcome!!!
> Thanks,
> Bill
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users

More information about the Mesa-users mailing list