Replies: 3 comments
-
@andreimesinger @JulianBMunoz I cc-ed you in case there are more boxes that you think can be useful. e.g. Mturns? |
Beta Was this translation helpful? Give feedback.
-
There are a couple of things to consider here. At the most fundamental level, essentially everything is easier in Python, so if things are just as fast to do in Python (which basically translates to "can be computed in a single line of numpy code") they should probably be done there. However, structurally speaking, the code is currently assuming that anything of importance is defined within the C output structs. Those struct definitions give us a single point of reference for all the possible fields we could want. We can certainly move away from this, and maybe it won't even be difficult to do so. However, this will mean that there will be at least two places to look for important boxes, which means everything will be slightly more complicated. |
Beta Was this translation helpful? Give feedback.
-
I think for some important boxes, we are actually defining them in Python, e.g. Then the question is which boxes might be useful to people outside the C. This is essentially why I am only thinking of moving |
Beta Was this translation helpful? Give feedback.
-
Describe what you would like to do
I'd like to have a discussion to see if this makes sense before making changes.
Clearly, the best way to output some boxes in order to, in most cases, get their globally averaged evolution is to use the
global_quantities
and/orlightcone_quantities
arguments when running lightcones. This seems to make more sense to move definitions of some useful boxes out of C, includingdxlya_dt_box
,dstarlya_dt_box
,dxion_source_dt_box
anddxheat_dt_box
. Is there any reason that we should minimize defining boxes in Python? e.g. in terms of RAM management.Beta Was this translation helpful? Give feedback.
All reactions