21cmfast / 21cmFAST

Official repository for 21cmFAST: a code for generating fast simulations of the cosmological 21cm signal
MIT License
58 stars 37 forks source link

define some boxes in python rather than C for easier outputting #229

Closed qyx268 closed 3 years ago

qyx268 commented 3 years ago

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/or lightcone_quantities arguments when running lightcones. This seems to make more sense to move definitions of some useful boxes out of C, including dxlya_dt_box, dstarlya_dt_box, dxion_source_dt_box and dxheat_dt_box. Is there any reason that we should minimize defining boxes in Python? e.g. in terms of RAM management.

qyx268 commented 3 years ago

@andreimesinger @JulianBMunoz I cc-ed you in case there are more boxes that you think can be useful. e.g. Mturns?

steven-murray commented 3 years ago

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.

qyx268 commented 3 years ago

I think for some important boxes, we are actually defining them in Python, e.g. z_re_box, dNrec_box, etc. The way I look at this is that perhaps we could distinguish the boxes by internal and external. We can consider boxes that will never be useful outside the 21cmFAST run as internal, such as those fftw boxes. However, anything that might be used in post-processing, because they are potentially useful, can be considered as external to C (as in that they have external usage outside the C). This includes those boxes that I just mentioned although the reason we have z_re_box, dNrec_box defined in Python now is because we need to use them at multiple redshifts.

Then the question is which boxes might be useful to people outside the C. This is essentially why I am only thinking of moving dxlya_dt_box, dstarlya_dt_box, dxion_source_dt_box and dxheat_dt_box to Python as they just begin to show usefulness outside C. I think if there is no RAM/speed issue when moving a box definition from C to Python, then we can simply move those when they need to be moved.