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

Philip Chang chang65 at uwm.edu
Thu Mar 17 13:45:55 UTC 2022


Hi everyone (once again),

First, I want to thank everyone's suggestions.  I have decide to stick 
with mesa for the nuclear burning library for my code mainly due to my 
familiarity with the codebase.

However, due to Rob Farmer's previous remark on one_zone_burn, I have 
adopted nuclear burning from solve_burn.f90 in star/private to my code.  
However, after getting it working as a standalone, I realize that I am 
confused about one thing.  In particular, the major issue that I have is 
that solve_burn.f90 does a simple implicit integration (backward Euler) 
for the mass fractions, but not the internal energy, i.e., temperature.  
This seems incorrect to me so I am hoping someone can explain to me how 
the internal energy is integrated in star when nuclear burning is 
included. This is especially confusing when the mass fractions change 
rapidly as it could in principle.

FYI, I am using 10398.  My apologies for using this old version, but 
more modern versions of mesa have changed the API somewhat which 
preclude me using a more recent version without changing my code 
significantly -- though this is anticipate sometime in the 
not-to-distant future.

Cheers,

Philip

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/20220317/429c63a2/attachment.htm>


More information about the Mesa-users mailing list