[Mesa-users] Models with mesa_204.net do not attain the lgTmax value

[Amar Aryan]

Hi Ebraheem,

Thank you for pointing this out. I see that the speed test was conducted on
a processor with 22 physical cores, and it was found that cases with more
variables (both structure and network) benefit more from parallel
execution. I expect utilizing the *20M_pre_ms_to_core_collapse *with
mesa_204.net to have a significantly large number of variables.

Actually, I have currently started the run with OMP_NUM_THREADS=24; if I
find the speed hampered significantly, I shall restart the run with
OMP_NUM_THREADS=16. Would you like to make a guess as to how many days it
could take to finish when only one model is running in my Studio with the
above-mentioned settings? Thank you again!

With best regards,
Amar

On Tue, Dec 10, 2024 at 11:36 PM Farag, Ebraheem <ebraheem.farag at yale.edu>
wrote:

> Hi Amar,
>
> > Finally, I set "export OMP_NUM_THREADS=24"
>
> Keep in mind that MESA doesn't scale well beyond 12 cores, you can see the
> Amdahl's law plots (Figure 47) in MESA III
> <https://ui.adsabs.harvard.edu/abs/2019ApJS..243...10P/abstract>. In my
> experience there is no benefit to using more than 16 cores, and in fact
> setting the number of threads higher can slow the code down. In your
> circumstance, with 8 efficiency cores, I'd probably set OMP_NUM_THREADS=16,
> as I would only want the p cores to be used (although mac os makes this
> choice for you).
>
> Goodluck!
>
> -EbF
>
> ------------------------------
> *From:* Amar Aryan <amararyan941 at gmail.com>
> *Sent:* Monday, December 9, 2024 11:39 PM
> *To:* Farag, Ebraheem <ebraheem.farag at yale.edu>
> *Cc:* mesa-users <mesa-users at lists.mesastar.org>
> *Subject:* Re: [Mesa-users] Models with mesa_204.net do not attain the
> lgTmax value
>
> 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/20241211/e0709d53/attachment.htm>