[mesa-users] inconsistent READs for ifort vs gfortran
Bill Paxton
paxton at kitp.ucsb.edu
Tue Dec 24 22:00:25 EST 2013
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff
Type: application/octet-stream
Size: 15544 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131224/330e9d82/attachment.obj>
-------------- next part --------------
(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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: helm_alloc.f
Type: application/octet-stream
Size: 14620 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131224/330e9d82/attachment-0001.obj>
-------------- next part --------------
I'm testing this with version 5766.
Any ideas welcome!!!
Thanks,
Bill
More information about the Mesa-users
mailing list