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

Thu Mar 17 17:44:22 UTC 2022

Hi Frank,

I believe that mesa must do a fully-coupled hydro+burn timestep. The 
question is how and how is this done operationally in mesa-star.  In 
particular star/solve_burn.f90 does a backward Euler (implicit) 
integration for a step dt.  This backward Euler step only does this for 
the mass fraction and appears to hold both density (which is ok) and 
temperature fixed (which I don't think is ok).

Now I am assuming that solve_burn.f90 is how mesa-star does nuclear 
burning.  Please correct me if I am wrong.

My question is how does the implicit time integration for the mass 
fractions done in star/solve_burn.f90 does the fully coupled hydro + 
burn timestep that you describe below and where in the code is this done.

Thanks.

Cheers,

Philip

On 3/17/22 11:58, Francis Timmes wrote:
> hi philip,
>
>> ... how the internal energy is integrated in star when nuclear burning is included.
> by default, mesa does a fully-coupled hydro + burn timestep.
> see figure 47 and appendix b.2 of mesa II.
> this is how the energy equation is self-consistently integrated.
> mesa V discusses energy conservation.
>
> an option exists to do a more traditional operator split evolution;
> hydro, then burn, hydro, then burn, etc. as you note, when the
> loose-coupling assumed by operator splitting becomes a poor approximation
> can lead to questions about consistency. this is one reason mesa adopted
> a fully-coupled approach from its inception.
>
> the burn modules can be used to build a standalone network.
> this network could subsequently be used, for but one example,
> in a explicit, 3d grmhd software instrument with an operator-split burn.
>
> fxt
>
>
>
>
>> On Mar 17, 2022, at 6:45 AM, Philip Chang via Mesa-users <mesa-users at lists.mesastar.org> wrote:
>>
>> 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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fui.adsabs.harvard.edu%2Fabs%2F2017ApJS..233...18L%2Fabstract&data=04%7C01%7Cchang65%40uwm.edu%7C9d5cb4bb47624195290908da08376cfc%7C0bca7ac3fcb64efd89eb6de97603cf21%7C0%7C0%7C637831331391508208%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=i8JW7RMGdTkKSP7D8pjfz3VSzugomvQHhTU%2F57q8BDk%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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mesastar.org%2Fmailman%2Flistinfo%2Fmesa-users&data=04%7C01%7Cchang65%40uwm.edu%7C9d5cb4bb47624195290908da08376cfc%7C0bca7ac3fcb64efd89eb6de97603cf21%7C0%7C0%7C637831331391508208%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=rLIotVVHRUCaxDemQ11kc4KM6N%2FdJi1frXwEENnBRcI%3D&reserved=0
>>>
>> _______________________________________________
>> mesa-users at lists.mesastar.org
>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mesastar.org%2Fmailman%2Flistinfo%2Fmesa-users&data=04%7C01%7Cchang65%40uwm.edu%7C9d5cb4bb47624195290908da08376cfc%7C0bca7ac3fcb64efd89eb6de97603cf21%7C0%7C0%7C637831331391508208%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=rLIotVVHRUCaxDemQ11kc4KM6N%2FdJi1frXwEENnBRcI%3D&reserved=0
>>