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

Thu Mar 17 22:09:03 UTC 2022

Hi all,

After looking carefully at the code, I realized that there was a change 
in r10398 compared to more modern versions of MESA and I must have 
misunderstood Rob Farmer's remark.  Indeed burn1_BE is disabled in 
r15140 and instead burn1_zone is used there instead, which uses 
net_1_zone_burn_const_density so indeed temperature is integrate at the 
same time as the mass fractions.  But this is not the case in older 
versions of mesa like r10398.

Cheers,

Philip

On 3/17/22 12:44, Philip Chang via Mesa-users wrote:
> 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%7C73c0c6e278334329a6f708da083dcdde%7C0bca7ac3fcb64efd89eb6de97603cf21%7C0%7C0%7C637831358796578978%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ADmC2MIIUcvxkBG0hFYlNz0e8FppmKpme2s6TtGZ6Ww%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%7C73c0c6e278334329a6f708da083dcdde%7C0bca7ac3fcb64efd89eb6de97603cf21%7C0%7C0%7C637831358796578978%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yGW1erh1Fbt8lhB%2BlOo8ug8eHkkLZJkdH9NbZluLFoo%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%7C73c0c6e278334329a6f708da083dcdde%7C0bca7ac3fcb64efd89eb6de97603cf21%7C0%7C0%7C637831358796578978%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yGW1erh1Fbt8lhB%2BlOo8ug8eHkkLZJkdH9NbZluLFoo%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%7C73c0c6e278334329a6f708da083dcdde%7C0bca7ac3fcb64efd89eb6de97603cf21%7C0%7C0%7C637831358796578978%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yGW1erh1Fbt8lhB%2BlOo8ug8eHkkLZJkdH9NbZluLFoo%3D&reserved=0 
>
>