amuse icon indicating copy to clipboard operation
amuse copied to clipboard

Setting metallicity in MESA r2208 seems to hang

Open LourensVeen opened this issue 1 year ago • 4 comments

Describe the bug From @spzwart:

m = Mesa(version="2208") m.parameters.metallicity = 0.04 or any other value for the metallicity, seems to hang.

Expected behavior The metallicity to be set accordingly.

LourensVeen avatar Nov 01 '24 17:11 LourensVeen

Weird. I can reproduce this, and it only hangs for metallicity, not for e.g. max_age_stop_condition. The python script and the mesa_worker are both pinned at 100% CPU, which suggests a communication issue. But why?

LourensVeen avatar Nov 03 '24 10:11 LourensVeen

With a bit of experimenting and looking at the source code, it seems that setting the metallicity causes a lookup of an initial model state (not sure which bits exactly) from a table. The MESA we ship comes with one such table, src/mesa/data/star_data/starting_models/zams_z2m2.data which is never used by AMUSE because AMUSE calculates the file name with two digits for the first number (these are the mantissa, and the second number is a negated and shifted base-10 exponent of the metallicity).

If the table isn't found, then the values will be computed, as hinted at in the docstring for the Mesa class:

If you order a metallicity you haven't used before, starting models will be computed automatically and saved in the mesa/src/data/star_data/starting_models directory (please be patient...).

For a metallicity of 4%, this calculation fails to converge:

m = Mesa(version="2208", redirection="file", redirect_file="mesa.log")
m.parameters.metallicity = 0.04

# in mesa.log

 done build_pre_ms_model
 stopping because of too many backups in a row          16




 evolve_to_zams ierr          -1

failed during attempt to create main sequence

If I try 0.001 instead, it logs a whole bunch of tables as it iterates towards a solution. It's been running for about 10 minutes now, not sure how long this is supposed to take...

One conclusion that we can already draw is that error handling in AMUSE is poor. There's no indication on the Python side that something went wrong on that z = 0.04 run, and if innocently setting a parameter is going to trigger a long-running calculation, then it would be good if a warning popped up telling the user this.

LourensVeen avatar Nov 03 '24 12:11 LourensVeen

Well, it finished, not sure how long it took because I worked on something else in the mean time. It doesn't seem to save the results in src/mesa/data/star_data/starting_models/, but perhaps they're elsewhere or not meant to be cached.

Once this is done, I can evolve a star (using the code in Listing 3.2 of the book) and that seems to work okay. The only thing I see there is that the age of the star remains 0 Myr, even after 100 1Myr timesteps. Not sure if that's supposed to happen...

LourensVeen avatar Nov 03 '24 12:11 LourensVeen

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 365 days if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Nov 18 '25 21:11 stale[bot]