Closed IvanNikolic21 closed 1 year ago
It seems to me that a straightforward, short term "fix" could be to do a check using the analytic EoR history (dQHII/dt = dnion/dt) if the results are reasonable and fall within the interpolation tables. If not, rather than having the code crash, it could just output a warning message and run without photon conservation, but with an alpha_esc that is decreased (just internally) by 0.2 (according to Park, Greig, Mesinger 2022). What do you think @BradGreig?
Hey @IvanNikolic21 @andreimesinger do you have the reionisation history available for this specific parameter set? (analytic, calibration or with Photon Cons turned off). I haven't found the time to run it myself. Just want to see which class it is, as there are a few different corners of parameter space that lead to different possible causes of failure.
I'm wondering if there might be an easier way to decide simply off the analytic and/or calibration curve. If the history is too extreme, one can then simply rule out the model rather than trying to sample it (since it shouldn't be allowed by most other priors).
Note, technically speaking just modifying alpha_esc by 0.2 would not necessarily be correct. It is 0.2 for the model considered in the paper, but it doesn't need to be uniformly 0.2 for all possible models. However, for this it is probably a reasonable approximation.
Thanks @BradGreig , I think @IvanNikolic21 mentioned that it had a super early EoR history, but he can comment more in detail. But indeed deciding based on the analytic curve is exactly what I am suggesting above. I don't think it is sufficient though to return a likelihood of zero in 21cmMC, since the code would in any case crash if the user is just running 21cmFAST. A more stable solution, imo is to do as I suggested above inside 21cmFAST: (i) using the analytic curve, check if tau_e is within, say 3 sigma of Planck, or if EoR ends before/after z= whatever; (ii) if it does, turn off photon conservation for that one run, and run without PC but with an internally decreased alpha_esc, printing out a corresponding warning. In the end these runs will not matter as they are already ruled out, but i think it is the most stable solution.
I'm open to either way, or even having a GLOBAL option that switches between the two behaviours. I.e., by default, raise an exception when it's going bananas (this exception can be handled in 21cmMC as a "non-fatal" exception, and a loglike of -inf returned, and within 21cmFAST it would just crash, but with a useful exception message). But you could switch on global_params.ignore_photoncons_errors = True
or something, and in that case it would only warn you, and do what @andreimesinger suggests.
Just to follow up on the EoR history for this particular parameter set. Here is the EoR history, and as I said, it ends very early. This curve is obtained w/o photo conservation, with alpha_esc scaled by 0.2
Hey @IvanNikolic21 @andreimesinger I did some further digging into this, mostly because an early EoR should be able to be handled by the Photon Conservation. Most of the problems I am familiar with occur for models with little to no star-formation, that is reionisation stagnates or never happens.
The cause of the segmentation fault in the above case is simply because it tries to access a function that hasn't yet been initialised. This has happened because you have a Z_HEAT_MAX = 15, and the first point just so happens to fall outside the conditions where the requisite function would have been initialised. By adding in this initialisation step, the model completes without segmentation fault.
I've created a PR with this change (#312), which should be able to handle this specific failure.
However, I think a broader discussion is required for how better to treat and handle failures of the photon conservation correction in the corners of parameter space.
brad's PR should solve the problem with PC when running py21cmmc and close this issue. A new issue should be raised for how to better deal with PC with very late EoR, which imo is a low-priority...
many thanks brad!
On Fri, 11 Nov 2022 at 08:21, Yuxiang Qin @.***> wrote:
brad's PR should solve the problem with PC when running py21cmmc and close this issue. A new issue should be raised for how to better deal with PC with very late EoR, which imo is a low-priority...
— Reply to this email directly, view it on GitHub https://github.com/21cmfast/21cmFAST/issues/311#issuecomment-1311320008, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADH2UAQDF4QWZDYFXVLN7GDWHXXXLANCNFSM6AAAAAAR2LIZKE . You are receiving this because you were mentioned.Message ID: @.***>
Describe the bug: 21cmFAST produces Segmentation Fault errors for certain values of parameters. This happens while running multinest within 21CMMC and only when using photon-conservation flag 'PHOTO_CONS=True'. Unfortunately, segmentation fault crashes the whole run when multinest is ran with mpirun.
To Reproduce: Using the following code with mpirun --map-by ppr:nproc:node run.py:
procudes the following error:
I investigated which parameters crash the code, and in this instance it's this one:
[({'ALPHA_ESC': -0.9482376575469971, 'ALPHA_STAR': 0.1368311643600464, 'ALPHA_STAR_MINI': 0.5, 'A_LW': 2.0, 'A_VCB': 1.0, 'BETA_LW': 0.6, 'BETA_VCB': 1.8, 'F_ESC10': -0.16299712657928467, 'F_ESC7_MINI': -2.0, 'F_H2_SHIELD': 0.0, 'F_STAR10': -0.5723588466644287, 'F_STAR7_MINI': -2.0, 'HII_EFF_FACTOR': 30.0, 'INHOMO_RECO': False, 'ION_Tvir_MIN': 4.69897, 'L_X': 40.0, 'L_X_MINI': 40.0, 'M_TURN': 8.044878363609314, 'N_RSD_STEPS': 20, 'X_RAY_SPEC_INDEX': 1.0, '_NU_X_THRESH': 500.0, '_name': 'AstroParams', '_t_STAR': 0.20997181951999666}, array(98568.))]
To see whether the same thing happens with 'PHOTO_CONS'=False, I launched a lightcone with the same parameters (only with alpha_esc scaled by -0.2, according to Park+22) and found no segmentation fault, while 'PHOTO_CONS'=True again reproduced the segmentation fault.
Expected behavior:
The parameters that create this problem are in the corners of the prior space. Therefore their EoR histories are somewhat exotic, in this case, escape fraction is 1.0 for almost all halos, and SFRD is quite high, with very low feedback. Therefore, this is only a problem in 21cmmc samplers, and only in the first few steps. Therefore, a solution could be to disregard the 'PHOTO_CONS' flag for certain parameter values if they are expected to crash, possibly scaling 'ALPHA_ESC' as well.