[mesa-users] testing mesa with ifort 13

Rob.Farmer Rob.Farmer at open.ac.uk
Wed Dec 18 16:01:50 EST 2013


Great work Bill on getting bit for bit working. So i'm testing mesa v5740 without the SDK and with ifort 13. Still only at the compiling step but will report back with the test data later.

So first a few warnings i ran into:

ifort: command line warning #10212: -fp-model precise evaluates in source precision with Fortran.
Apparently  -fp-model precise is the same as -fp-model source (only matters for c++) so you should switch the compile option to source otherwise you get a warning message after every compiler line.

-xW is deprecated and ifort -help deprecated suggests replacing it with -msse2

icc: command line warning #10159: invalid argument for option '-m' (-mpc64) maybe meant -m64? as set in mtx/make/makefile line 102

Then  i get this

<                                                       B   -1.6215408275458795D-01    1.6391349023885562D+00   -3.8454229229650999D-02   -2.8158487838788577D+00
>                                                       B   -1.6215408275458812D-01    1.6391349023885562D+00   -3.8454229229650999D-02   -2.8158487838788577D+00
<                                                      B1    4.8857961179302795D-01   -7.1218664137347662D-02    7.4907772296032871D-01
<                                                      B2   -1.0851063829787229D+00    9.9999999999999956D-01    1.7975291695264239D+01
>                                                      B1    4.8857961179302783D-01   -7.1218664137347662D-02    7.4907772296032871D-01
>                                                      B2   -1.0851063829787233D+00    1.0000000000000000D+00    1.7975291695264243D+01
<                                               A1_init*X    1.0000000000000002D+00    2.0000000000000004D+00    2.9999999999999996D+00
<                                                fac A1*X    1.0000000000000004D+00    2.0000000000000004D+00    3.0000000000000000D+00
>                                               A1_init*X    1.0000000000000000D+00    2.0000000000000000D+00    2.9999999999999996D+00
>                                                fac A1*X    1.0000000000000000D+00    2.0000000000000000D+00    3.0000000000000000D+00
<                                               A2_init*X    1.0999999999999994D+00    2.1000000000000001D+00    3.1000000000000001D+00
<                                                fac A2*X    1.0999999999999994D+00    2.1000000000000001D+00    3.1000000000000001D+00
>                                               A2_init*X    1.1000000000000001D+00    2.1000000000000001D+00    3.1000000000000001D+00
>                                                fac A2*X    1.0999999999999999D+00    2.1000000000000001D+00    3.1000000000000001D+00

TEST FAILED -- compare test_output to tmp.txt

Its failing on the following checks:


Turns out i need to switch to using the mesa{lapack,blas} rather than the system versions

Then everything was gong well until:

./public -I../private -I../../include -warn all -warn nounused -implicitnone  -O2 -c -free -fpp ../public/rates_lib.f
ifort: error #10105: /home/Rob/intel/composer_xe_2013.2.146/bin/intel64/fortcom: core dumped
ifort: error #10106: Fatal error in /home/Rob/intel/composer_xe_2013.2.146/bin/intel64/fortcom, terminated by unknown signal(139)
compilation aborted for ../public/rates_lib.f (code 1)
make: *** [rates_lib.o] Error 1


./build_and_test FAILED

Yah the compiler itself crashed

Now i've seen this before and usually fixes itself if i replace a USE MODULE, ONLY FUNC1,FUNC2... line  with a USE MODULE so will investigate and report back.


From: Bill Paxton [paxton at kitp.ucsb.edu]
Sent: 17 December 2013 21:10
To: Aaron Dotter
Cc: MESA users group
Subject: Re: [mesa-users] testing mesa with ifort 13

one other thing that I forgot to mention.

I've hit cases with gfortran where T**4 was not bit-for-bit identical to T*T*T*T -- here's one

          T    5.7065090704240729D+03
       T**4    1.0604301026231640D+15
    T*T*T*T    1.0604301026231639D+15

I had hoped that taking integer powers would be okay, but somehow gfortran found a way to make it a problem.

Perhaps there's a flag for that too!   But if not, the use of ** may need to be replaced everywhere.  ugh.
I've done a partial sweep of the code converting these, but it isn't yet complete.
It isn't a problem when we're only using gfortran (at least not so far), but it is necessary for consistency with ifort (suprise, ifort seems to give the same value for T**4 and T*T*T*T -- who would have guessed they'd be the good guys!).


On Dec 17, 2013, at 11:47 AM, Bill Paxton wrote:

On Dec 17, 2013, at 11:17 AM, Aaron Dotter wrote:

I hope you'll do us the favor of spelling out the "twern't nothin" process

main thing is to get bit-for-bit consistent results from math lib routines (log, exp, etc)
accuracy is not necessary, but it is sufficient, so we switch to crlibm in place of libm.
I've added crlibm to mesa as a new module; seems to be very little performance cost.

second, you need to fix the order of evaluation of expressions like a + b + c.
because of round-off (a + b) + c might not be bit-for-bit same as a + (b + c),
and compilers can play with order of evaluation as part of optimization.
but happily, there's a compiler flag to prevent this -- for gfortran, it is -fprotect-parens

I was afraid at 1st that I'd need to edit every case like a + b + c to add explicit parens.
But now I'm hopeful that the "standard" of left-association for fortran will take care of this.
i.e., I hope a + b + c will be always be evaluated as (a+b)+c when you add -fprotect-parens.

ifort also has analogous flags, but I'm not yet able to tell if paren's will be a problem there.

finally, to keep diff happy you also need to add this flag for gfortran: -fno-sign-zero
otherwise, it will print -0d0 on some machines and 0d0 on others.

the values for testing with diff are all written using 1p26d16 format to get full precision.
if you use write(*,*), you'll get different rounding on different machines.

BTW: do NOT use the gfortran flags -ffloat-store -mpc64 unless you want to make things run very slowly.
I tried both of those briefly, but they're gone again now.  Don't worry: they were not in the previous mesa release.


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!
mesa-users mailing list
mesa-users at lists.sourceforge.net

-- The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302).

More information about the Mesa-users mailing list