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

[Philip Chang]

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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20220218/4a9e5c3d/attachment.htm>