[Mesa-users] Models with mesa_204.net do not attain the lgTmax value
Amar Aryan
amararyan941 at gmail.com
Tue Dec 10 04:39:11 UTC 2024
Hi Ebraheem,
Many thanks for your reply. It's never too late :-). In the meantime, I
could get my models fully evolved up to the stage of the onset of core
collapse utilizing the "approx21_cr60_plus_co56.net" network and with good
temporal/spatial resolution.
*For the whole run:*
*max_abs_rel_run_E_err = -1 ! default is unset, but it seems set to 1d-2 in
your inlist.*
*For a given timestep:*
*limit_for_rel_error_in_energy_conservation = 1d-4 ! default*
*hard_limit_for_rel_error_in_energy_conservation = 1d-3 ! default*
For my case, yes, max_abs_rel_run_E_err was 1d-2, although, I shall use
'-1' in my new run. I had limit_for_rel_error_in_energy_conservation =
1d-7 and hard_limit_for_rel_error_in_energy_conservation = 1d-6 in
inlist_common. Also, these were set to
limit_for_rel_error_in_energy_conservation
= 1d-3 and hard_limit_for_rel_error_in_energy_conservation = 1d-2 in later
inlists (inlist_to_lgTmax and inlist_to_cc) for the models which failed (I
still use these values in my new run).
The stopping conditions that I use in inlist_to_lgTmax is:
log_max_temp_upper_limit
= 9.600d0
Thanks for your suggestions regarding op_split_burn_minT. Earlier it was
set to 2.5, now I decreased it to 1.5.
Finally, I set "export OMP_NUM_THREADS=24". (Our Studio has 24 (16
performance + 8 efficiency) cores)
With the above changes employed, I start the run again with only one model
running on our STudio. I shall keep you updated with the results. Thank you
again for your time in looking at such an old query!
With best regards,
Amar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20241210/d943a210/attachment.htm>
More information about the Mesa-users
mailing list