[mesa-users] mesa 5819: bit-for-bit identical results: Mac or Linux, gfortran or ifort

[Bill Paxton]

Happy New Year!

The year is off to a good start for me since mesa is now getting bit-for-bit identical results on Mac and Linux, using either gfortran or ifort.  Special thanks to the folks who set up accounts for me to run tests on their machines: Ed Brown, Dean Townsley, Josiah Schwab, Brian Chaboyer, Ben Brown, Raphael Hirschi (Sam Jones), and Anwesh Mazumdar.

To check bit-for-bit consistency, the star test scripts "diff" the final model and the final profile data for 60 of the cases in the test suite against expected results included in the download.  This covers a broad range of cases: 1M pre-ms through he core flash to cool wd, massive rotating stars from zams to core collapse, nova bursts, a cooling brown dwarf, irradiated planets, etc.  

Note that we check using "diff" rather than "ndiff", so any difference in the output will show up as a failure.  And we check a large amount of output by considering the entire final model and entire final profile (e.g., in the 25M_z2m2_high_rotation case, these files are 2.1 MB and 5.5 MB respectively).   In addition to checking the end of run results, each test does a restart and confirms that ./re is giving exactly the same final output as ./rn.

The tests have been run on Macs with OSX 10.6.8, 10.8.5, and 10.9, and Linux with Ubuntu, Debian, RedHat, and Fedora.  We've used machines with 4, 8, 12, and 16 cores with OMP_NUM_THREADS set to the number of cores, so we are checking to ensure that degree of parallel execution doesn't change the results.

The new ifort (version 14) is able to compile the new mesa, so we can now use it in addition to gfortran and can select -O2 optimization for both compilers.  We have one instance for ifort on Linux (Anwesh) and one on Mac (Ben), and both give identical results to the gfortran runs.  BTW: I've only run both ifort and gfortran on a single machine (Ben's) so I can't make general statements about relative performance -- but on Ben's 8 core Mac ifort ran the test suite about 15% faster than gfortran.  

To get bit-for-bit identical results required the addition of a new mesa module, crlibm, to provide consistent results for math functions such as log, exp, sin, and cos (see http://lipforge.ens-lyon.fr/www/crlibm).   We also had to switch to using our own routine for converting from strings to doubles since ifort and gfortran sometimes give different results for reads.  I put the conversion routine, str_to_double, in crlibm_lib since it uses crlibm to do the powers of 10.  This routine is used for reading data files in atm, chem, eos, kap, rates, and star.

The two compilers also sometimes give different results for taking a double to an integer power greater than 2, so I had to get rid of a lot of **'s in the code.  Happily both compilers have flags to preserve parentheses and enforce left-associativity so expressions like a+b+c are evaluated as (a+b)+c -- I was afraid I might have to add explicit parens everywhere, but I got lucky on that one.

If you'd like to test your machine for consistency, you can simply run the star test_suite and search for "failed" in the terminal output.  To run it, do

cd star/test_suite
./each_test_run

The terminal output for each test case looks similar to this for the "7M_prems_to_AGB" test:

build_and_run 7M_prems_to_AGB
   start 02:30:00
  finish 02:33:35
stop because log_surface_luminosity >= log_L_upper_limit
                  runtime, retries, backups, steps         3.4         3.5         6         0      2264
7M_prems_to_AGB final.mod matches final_check.mod after ./rn
7M_prems_to_AGB matches final_profile.data after ./rn
7M_prems_to_AGB final.mod matches final_check.mod after ./re x200
7M_prems_to_AGB matches final_profile.data after ./re x200

On a new 16 core machine the complete test suite can finish in under 3 hours; on an older machine it can take over 9 hours; on a 2 core laptop it might take most of a day (I've never tried it!).     If you get a failure, please let me know!

So now we can get results that are exactly reproducible on different platforms rather than just sort-of-approximately similar.  That will be a big help for debugging (can't find the bug if can't reproduce it), and I expect it will encourage "cross-platform-collaboration" as well.  All in all, it is a good start to the new year!  ;D

--------------------------------------------------------------------------------------

Other changes in this release:

Josiah -- Fix typo in coulomb corrections for ecapture reactions

Pablo -- Fixes for binary timesteps and implicit Ritter scheme

Rich -- Updated to gyre 2.4; many improvements including a fix for a memory leak.

Thanks to suggestions from Diego Bossini, we now have an additional control for selecting Type2 vs Type1 opacities using dZ = Z - Zbase.  NOTE: if your model does helium burning, you should be using this!!  Here are the relevant lines from controls.defaults:
      
      ! Type2 opacities for extra C/O during and after He burning
         use_Type2_opacities = .false.
         Zbase = -1 ! the base metallicity for the Type2 kap evaluations.
   
         ! switch to Type1 if X too large
         kap_Type2_full_off_X = 0.71d0 ! Type2 is full off for X >= this
         kap_Type2_full_on_X = 0.70d0 ! Type2 can be full on for X <= this
   
         ! switch to Type1 if dZ too small (dZ = Z - Zbase)
         kap_Type2_full_off_dZ = 0.001d0 ! Type2 is full off for dZ <= this
         kap_Type2_full_on_dZ = 0.01d0 ! Type2 can be full on for dZ >= this
         
         ! X and dZ terms are multiplied to get actual fraction of Type2

            ! the fraction of Type2 is calculated for each cell
            ! depending on the X and dZ for that cell.

            ! So you can be using Type1 in cells where X is large or dZ is small,
            ! while at the same time you can be using Type2 where X is small and dZ is large. 
            ! When frac_Type2 is > 0 and < 1, then both Type1 and Type2 are evaluated and
            ! combined linearly as (1-frac_Type2)*kap_type1 + frac_Type2*kap_type2.
            ! Add "kap_frac_Type2" to your profile columns list to see frac_Type2 for each cell.


New defaults for angular momentum factors 

         am_nu_DSI_factor = -1 ! < 0 means use D_DSI_factor
         am_nu_SH_factor = -1 ! < 0 means use D_SH_factor
         am_nu_SSI_factor = -1 ! < 0 means use D_SSI_factor
         am_nu_ES_factor = -1 ! < 0 means use D_ES_factor
         am_nu_GSF_factor = -1 ! < 0 means use D_GSF_factor
         am_nu_ST_factor = -1 ! < 0 means use D_ST_factor
         am_nu_visc_factor = -1 ! < 0 means use D_visc_factor


optional environment variables MESA_OP_MONO_DATA_PATH and MESA_OP_MONO_DATA_CACHE_FILENAME


Cheers,
Bill


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20140105/4f9e58e2/attachment.html>