[Mesa-users] Simple one zone nuclear burning call using MESA
michael.zingale at stonybrook.edu
Sat Feb 19 13:43:17 UTC 2022
Hi Philip, as yet another suggestion, you can take a look at the ports of a
lot of networks (including aprox nets) to C++ that we use in our codes:
https://github.com/amrex-astro/Microphysics . These all run on GPUs or
CPUs and you can easily create a new net in this infrastructure with
pynucastro (https://github.com/pynucastro/pynucastro) -- it can directly
output the C++ RHS for the integrator. The main issue is that we use a lot
of AMReX data structures to do the GPU-ing via C++ lambda-capturing, so
that might make it harder to integrate into your code. You might also be
able to write a backend of pynucastro to output the C++ or Fortran directly
in the form your code needs.
On Fri, Feb 18, 2022 at 5:25 PM Philip Chang via Mesa-users <
mesa-users at lists.mesastar.org> wrote:
> Hi Rob,
> Thanks for the suggestion. Skynet is a possibility, but it looks like it
> is geared toward r-process and large networks, whereas I am aiming for an
> alpha chain like approx19. But I will reach out to see if skynet can be
> used with approximate networks.
> In the meantime, would the equivalent of one zone burn in star/ be
> solve_burn on star/private? Should I be modelling a burning routine though
> Philip Chang
> On 2/18/22 14:51, Rob Farmer wrote:
> 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
> > 3. There is a lot of allocations and deallocation per call to nuclear
> The only way to know if it's significant to your runtime is to profile the
> > 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
> Have you looked at skynet
> 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.
> 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
>> 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
>> 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
>> 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.
>> Phil Chang
>> mesa-users at lists.mesastar.org
> mesa-users at lists.mesastar.org
Professor of Physics and Astronomy
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY
*e-mail*: michael.zingale at stonybrook.edu
github: https://github.com/zingale <http://github.com/zingale>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mesa-users