[Mesa-users] Convergence of massive Population III stars

Jake Hassan jakebhassan at gmail.com
Sat Jan 25 02:08:59 UTC 2025


Hi everyone,
I'm attempting to model very massive Population III stars using MESA r24.08.1 (SDK version 24.10.1), based on the parameters described in Yoon et al. 2012 (https://ui.adsabs.harvard.edu/abs/2012A%26A...542A.113Y/abstract). For now I'm focusing on nonrotating metal-free stars, and I've been able to evolve ones with initial masses up to 80 Msun to core collapse.

For higher initial masses though (still nonrotating), my models go awry in the later stages. For example, at 90 Msun the evolution gets very close to core collapse, but suddenly becomes haywire and the timestep plummets (see attached images). For 100 Msun, it only goes as far as O-burning before halting for several hundred steps and eventually evolving erratically (also attached). In both cases it seems to be associated with "logT > hydro_mtx_max_allowed_logT" and "logRho > hydro_mtx_max_allowed_logRho" errors, though raising hydro_mtx_max_allowed_logT and hydro_mtx_max_allowed_logRho to higher values did not fix the issue.

I suspect the problem is related to overshooting. I've been using the 20M_pre_ms_to_core_collapse test suite as a guide, and it includes a small amount of overshooting in Z-burning regions for numerical stability (with overshoot_f = 0.005). This is necessary for my inlists to converge too, since excluding it would cause even my 80 Msun models to diverge in the same manner I described for the 90 Msun models. I haven't found a value of overshoot_f that yields convergence at higher masses, but 0.017 seems to work the best for the 100 Msun model, allowing it to get as far as Si burning before going haywire (higher or lower values than 0.017 won't get past O-burning). However, 0.017 prevents the 90 Msun model from reaching as far as 0.005 would.

I would appreciate any advice on this. I've attached two inlists: inlist_to_end_core_he_burn evolves the star from pre-MS to the end of He burning, while inlist_to_cc evolves it from that point to core collapse. The only differences between these files are the termination conditions and whether we load a saved model. Let me know if anything else would be helpful.

Thanks,
Jake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20250124/03b7df6f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 100Msun_step1530.png
Type: image/png
Size: 66633 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20250124/03b7df6f/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 90Msun_step1360.png
Type: image/png
Size: 67171 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20250124/03b7df6f/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 90Msun_step1350.png
Type: image/png
Size: 67188 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20250124/03b7df6f/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_to_cc
Type: application/octet-stream
Size: 3905 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20250124/03b7df6f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_to_end_core_he_burn
Type: application/octet-stream
Size: 3981 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20250124/03b7df6f/attachment-0001.obj>


More information about the Mesa-users mailing list