[Mesa-users] Simple one zone nuclear burning call using MESA

[Rob Farmer]

Hi,
This is prefaced that the one zone burn code is not well tested or used. If
something is not being used by star/ then there is likely a) bugs b) lack
of development c) things that no longer make sense.

>1. There are a load of pointers that are allocated on the module level
like xin, xin_copy, etc.

Yes we need to allocate things at runtime as we don't know the  number of
isotopes or number of reactions until runtime.

> 2. net_1_zone_burn_const_density takes two external functions,
get_eos_info_for_burn_at_const_density and burn_finish_substep.

Lack of development. Though that has been cleaned up in recent versions of
mesa.

> 3. There is a lot of allocations and deallocation per call to nuclear
burning.

The only way to know if it's significant to your runtime is to profile the
code.

> 4. mod_one_zone_burn.f is a bit convoluted in how it runs.  I am
wondering if there are any other recommendations for good implementation
nuclear burning networks that can be integrated into a hydrodynamic
code.

Have you looked at skynet
https://ui.adsabs.harvard.edu/abs/2017ApJS..233...18L/abstract ?

Prompted by this and other recent  questions on using the one zone burn, I
will be removing the one zone burner for the next mesa release.

Rob


On Fri, 18 Feb 2022 at 20:56, Philip Chang via Mesa-users <
mesa-users at lists.mesastar.org> wrote:

> Hi All,
>
> Just wondering if anyone has any advice.  I am working with a student
> integrating nuclear burning in my moving-mesh code, MANGA.  I've
> previously integrated the mesa eos module into MANGA, e.g., compiling
> the mesa libraries and writing glue code to called the mesa libraries in
> MANGA.  I now want to integrate the nuclear burning module in MESA into
> MANGA.
>
> The version of mesa that I am using is release 10398.  I cannot upgrade
> yet as MESA moves from including crlibm to including crlibm in mesasdk
> release 12778, which causes issues with compilation and linking with MANGA.
>
> The mesa nuclear burning module will be called as a one zone burn at
> constant density per mesh point.  As such I am using
> net/test/src/mod_one_zone_burn.f as the example.  However, as I read it,
> I do not quite understand all the choices that was made it's
> development.  Hopefully someone can answer some of the questions that I
> have.
>
> 1. There are a load of pointers that are allocated on the module level
> like xin, xin_copy, etc.  It is not clear why they are declared as
> pointers rather than arrays outright.  My guess is that size of the
> array is not necessarily known at compile time because you can use
> different networks.  Is this correct?
>
> 2. net_1_zone_burn_const_density takes two external functions,
> get_eos_info_for_burn_at_const_density and burn_finish_substep.
> get_eos_for_burn_at_const_density explicitly uses the HELMHOLTZ eos,
> while burner_finish_substep using the mesa eos module.  Is there a
> reason for the difference?
>
> 3. There is a lot of allocations and deallocation per call to nuclear
> burning. For instance, there is one allocation and deallocation per call
> to burner_finish_substep.  This seems excessive to me.  Usually
> allocation on the stack is much faster than allocation on the heap
> because of the (usually) expensive malloc call.  I'm slightly concerned
> about the number of allocs in my MANGA code, as the usual usage for
> MANGA is running on a large node with 16-32+ threads per processes.  As
> each thread will call the nuclear burning step simultaneously, I am
> concerned that the number of allocs will really slow the nuclear burning
> calls.  Is this necessarily a major concern?
>
> 4. mod_one_zone_burn.f is a bit convoluted in how it runs.  I am
> wondering if there are any other recommendations for good implementation
> nuclear burning networks that can be integrated into a hydrodynamic
> code.  I have looked at Frank Timmes cococubed site which has aprox13.
> This is significantly simpler than mesa, but I know that it is not
> thread-safe, which is a necessity.
>
> Thanks.
>
> Cheers,
>
> Phil Chang
>
> _______________________________________________
> mesa-users at lists.mesastar.org
> https://lists.mesastar.org/mailman/listinfo/mesa-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20220218/51ec7b61/attachment.htm>