inconsistency between photo and mod file restarts

[Debraheem]

Inspired by testing the following merged branch: https://github.com/MESAHub/mesa/pull/597.

This branch implemented some mathematical identities into the thermal neutrino module which should in theory be identical to the math it replaced. In practice, this yielded bit for bit differences in the neutrino module output at the 10^-12 to 10^-15 level.

In measuring the impact this would have on the MESA test_suite, Warrick found that the final Fe core masses from the '20Msun_pre_ms_to_cc’ test_suite were different between runs with and without these minor bit for bit changes. (a change from 1.5 to 1.58 Msun)

Initially I thought the '20Msun_pre_ms_to_cc’ test_suite might just be extremely sensative to numerics, which was a little disconcerting. However, I think I managed to deduce that most of this difference in Fe core mass convergence was a result of opting for .mod file over photo restarts in the '20Msun_pre_ms_to_cc’ test_suite.

20M_pre_ms_to_core_collapse_restarts_example.zip mod_restart_output.txt photo_restart_output.txt

Attached is an example where I’ve also provided the output from both runs running with a .mod file restart (using the rn executable) and .photo restart (using the run_all_photo_restarts executable). The .mod file restart leads to a final Fe core mass of ~ 1.55 Msun and the photo restart yields ~ 1.61 Msun.

Besides prompting some tweaks to the '20Msun_pre_ms_to_cc’ test_suite, this experiment begs the question of what information is being lost on a .mod file restart that could result in these differences. I’ve always been a proponent of restarting from photos as a opposed to .mod files, although I thought the .mod files were a little more robust in recalculating the structure. Since we use .mod file restarts for testing the test_suite, this could make it hard to properly test or achieve the desired convergence we’d like to see out of test_suites like '20Msun_pre_ms_to_cc' and '12Msun_pre_ms_to_cc' without moving to photo restarts.

All in all, some important model information is missing when restarting from a .mod file in a massive star run.

I’m documenting this behavior in this thread so we can have some discussion on this topic and hopefully a better long term solution. Perhaps there is something missing or not being recalculated correctly in a .mod restart which can be identified and fixed.

[fxt44]

just a comment. plain text mod files were originally designed as a way for developers to quickly share a problem across machine architectures and set-ups. they were never intended to replace the binary, bit-for-bit, photos as the proper way to restart a run on a specific machine. yet, over time, mod files have become the dominant restart mode in the test suite. hence an implicit recommendation to users that mod files are what should be used for quality restarts.

[evbauer]

Thanks Frank! Useful to have a sense of how this arose organically. The big downside of our current binary photos is that they aren't necessarily portable across different machine architectures and MESA versions. That means we can't use them to replace starting models in general. And for the test suite specifically, we can't use photos as a starting point for runs that skip the optional inlists.

Recently I've been wondering if maybe we could develop something like a .mod5 file format that could use hdf5 (for portability across different machines) to fill some of the role of both .mod files and photos. We'd still have to do some thinking about portability across different MESA versions, since the content of photos can evolve as MESA gets developed, but this still might prove to be a useful infrastructure improvement.

[fxt44]

in the shorter term, i would like to see the test suite evolve back to using mostly photos, with a few mod files cases to check that functionality.

in the longer term, a portable, bit-for-bit, hdf5 restart solution that eliminates mod and photos seems like a good path forward. certainly we've talked about this several times!

[Debraheem]

In the near term, It could be useful to run a full the test_suite with photo restarts and compare the results to .mod restarts. My recent massive star testing suggests that the results should be almost identical for H and He burning, so perhaps the .mod ascii files are fine in most situations.

I like the longer term idea of opting for an hdf5 restart solution. Perhaps this could be bundled with a future project to convert the eos and kap data into an hdf5 format.

[fxt44]

may the great hd5 migration of 2024 begin!

[afonsojantarada]

Hi, my name is João Jantarada and i am a PhD candidate from Lisbon. I was trying to reproduce the evolution of a 20 solar mass star from the pre-ZAMS to its core collapse . Somehow, when i tried to run the code, it fails to create the final.mod. May you help me to solve that mistake?

[Debraheem]

Hello @afonsojantarada, it seems your question would be more appropriate for the main MESA mailing list, see https://lists.mesastar.org/mailman/listinfo/mesa-users. The mesa-users mailing-list is the perfect place for this. Just try to document your issue as best you can and share all the relevant files I've mentioned below! I would suggest sharing a clean version of your model directory and a text file of the full output so it is clear to those reading your help request how best to help you.

"Somehow, when i tried to run the code, it fails to create the final.mod. "

I wouldn't know where to begin answering a question like this without seeing your output and inlists etc.