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

Sat Feb 19 13:31:31 UTC 2022

Hi Philip,

 From my experiences of running the MESA one-zone burner in WD 
disruption models by WDs/NSs/BHs, I can highly recommend opting for 
Torch (https://cococubed.com/code_pages/net_torch.shtml), and indeed 
Skynet. Torch has been several orders of magnitude faster and 
memory-friendly in the NSE regimes, mostly because it is optimised to 
deal with such regimes effectively. As a specific example, a 
one-particle history through the NSE (e.g. TMax = 5.e9K) could eat up 
gigabytes of memory and run about a day on single core in MESA burner, 
and execute within minutes in Torch, taking few Megs of space.

The difference would matter when something extreme happens to WDs (e.g. 
direct collisions, disruptions of massive WDs etc).

Cheers,
Alexey

On 2022-02-19 00:24, Philip Chang via Mesa-users 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fui.adsabs.harvard.edu%2Fabs%2F2017ApJS..233...18L%2Fabstract&data=04%7C01%7Cbobrick%40campus.technion.ac.il%7Cd428ce3adcfe4a27135308d9f32d9828%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637808199426710030%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=S7%2Fe1jm9%2F9wjOsO53%2BgeTRkLnSL4uwPo2QiddPQqT9s%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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mesastar.org%2Fmailman%2Flistinfo%2Fmesa-users&data=04%7C01%7Cbobrick%40campus.technion.ac.il%7Cd428ce3adcfe4a27135308d9f32d9828%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637808199426710030%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=t1JWyfL1kjVRR2PNraZ4hPFtltCxXX69dC%2BNW2IZBUk%3D&reserved=0>
>>
> *External e-mail, be judicious when opening attachments or links *
>
>
> _______________________________________________
> mesa-users at lists.mesastar.org
> https://lists.mesastar.org/mailman/listinfo/mesa-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20220219/70cc08ac/attachment.htm>