NSE_NET check update #1932
NSE_NET check update #1932
Conversation
…ophysics into remove_divide_in_screening
…nto nse_check_update
|
This depends on networks regenerated after pynucastro/pynucastro#1244 is merged. I'll open another pr with the regenerated networks and this change for testing. |
…nto nse_check_update
…nto nse_check_update
…nto nse_check_update
|
One of the "edge" case in |
| constexpr int NumNSERatePairs = 22; | ||
|
|
||
| inline AMREX_GPU_MANAGED amrex::Array2D<std::int8_t, 1, NumNSERatePairs, 1, 10, amrex::Order::C> rate_pair_data { | ||
| 1, 3, -1, 4, -1, -1, 3, 4, 1, 59, // fr: p_C12_to_N13_reaclib, rr: N13_to_p_C12_derived |
There was a problem hiding this comment.
we can eventually make this even easier to read by using the 1-based species keys here, like, like H1 instead of 1, C12 instead of 3, ...
There was a problem hiding this comment.
indeed. I'll make a pr in pynucastro
There was a problem hiding this comment.
done in pynucastro/pynucastro#1254 and regenerated the nets
2 participants
Do some updates for the NSE_NET check. The primary change is to do all the rate filtering when writing out the rate index using pynucastro instead of doing it at runtime.
I made
in_single_group()strictly to check for ONE group. Previously I optionally allow two groups: one for the light-isotope-group and the other one. If there are no neutron in the net, the definition for NSE configuration is even looser, where I only check for nuclei after si28 and see if they form a separate group for odd Z and even Z. I don't think this is correct because when we have configurations like this, this means that the integrated mass abundance will NOT be the same as the NSE abundance. In other words, if the network is intrinsically compatible with NSE, then this should not be needed.