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

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.

Mike

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
> this?
>
> Cheers,
>
> Philip Chang
> On 2/18/22 14:51, Rob Farmer wrote:
>
> 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
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fui.adsabs.harvard.edu%2Fabs%2F2017ApJS..233...18L%2Fabstract&data=04%7C01%7Cchang65%40uwm.edu%7C8c9c756e86ae49ce1c0208d9f3208436%7C0bca7ac3fcb64efd89eb6de97603cf21%7C0%7C0%7C637808144207856875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3OWe0ehHs9kSSznpPbdXFVwJJebozn%2BI3nSl6jmKZsU%3D&reserved=0>
> ?
>
> 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
>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mesastar.org%2Fmailman%2Flistinfo%2Fmesa-users&data=04%7C01%7Cchang65%40uwm.edu%7C8c9c756e86ae49ce1c0208d9f3208436%7C0bca7ac3fcb64efd89eb6de97603cf21%7C0%7C0%7C637808144207856875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4NeiDgT6bxWkKk1CLaOZ0qXvr71KwuoSAE%2F%2Bnm78GJs%3D&reserved=0>
>>
>> _______________________________________________
> mesa-users at lists.mesastar.org
> https://lists.mesastar.org/mailman/listinfo/mesa-users
>
>

-- 
Michael Zingale
Professor of Physics and Astronomy

Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY
11794-3800
*phone*:  631-632-8225
*e-mail*: michael.zingale at stonybrook.edu
*web*: https://zingale.github.io
github: https://github.com/zingale <http://github.com/zingale>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20220219/fc00ac32/attachment.htm>