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

[Philip Chang]

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