The current behvaiour using the halo sampler in both run_coeval and run_lightcone is to simply loop through each redshift in reverse order at the beginning to generate the halo populations. This has created some issues with the caching, recursive generation, and run_coeval.
The same parameter set + random seed can result in different output, resulting from the fact the initial halo sample is at the lowest redshift:
In run_lightcone this is relatively mild, since the cadence is set by the global parameters, a lightcone ending at z=6 will have a different halo sample at z=10 than the same parameter set run to z=8.
In run_coeval, however, the halo population is dependent on the requested redshifts. Since halo populations are always calculated at the requested redshifts, and the time between snapshots determines the sampling.
This can be controlled slightly using user_params.STOC_MINIMUM_Z, however this is in the framework of the recursive generation, which has issues (#363) and will simply step forward in time by ZPRIME_STEP_FACTOR until it reaches STOC_MINIMUM_Z, and calculated the required halo populations. Using this parameter we can evolve from a similar minimum redshift, however due to using the multiplicative factor the redshift will not be exactly the same, and the effect will be similar to a change in random seed.
If we use run_coeval with multiple redshifts and USE_TS_FLUCT or INHOMO_RECO, it is possible to get two snapshots very close to each other, since the required redshifts are inserted into the list obtained for the spin temperatures. If the sampler tries to generate progenitors too close together, issues can arise. I know that the error in the sampler increases the smaller the timestep is, but I have not fully quantified this.
It will be necessary to examine how the cadence of the halo sampler should relate to the cadence of the spin temperature / recombinations, as well as the user-defined redshifts in run_coeval.
The current behvaiour using the halo sampler in both
run_coevalandrun_lightconeis to simply loop through each redshift in reverse order at the beginning to generate the halo populations. This has created some issues with the caching, recursive generation, andrun_coeval.The same parameter set + random seed can result in different output, resulting from the fact the initial halo sample is at the lowest redshift:
run_lightconethis is relatively mild, since the cadence is set by the global parameters, a lightcone ending at z=6 will have a different halo sample at z=10 than the same parameter set run to z=8.run_coeval, however, the halo population is dependent on the requested redshifts. Since halo populations are always calculated at the requested redshifts, and the time between snapshots determines the sampling.user_params.STOC_MINIMUM_Z, however this is in the framework of the recursive generation, which has issues (#363) and will simply step forward in time by ZPRIME_STEP_FACTOR until it reaches STOC_MINIMUM_Z, and calculated the required halo populations. Using this parameter we can evolve from a similar minimum redshift, however due to using the multiplicative factor the redshift will not be exactly the same, and the effect will be similar to a change in random seed.If we use
run_coevalwith multiple redshifts andUSE_TS_FLUCTorINHOMO_RECO, it is possible to get two snapshots very close to each other, since the required redshifts are inserted into the list obtained for the spin temperatures. If the sampler tries to generate progenitors too close together, issues can arise. I know that the error in the sampler increases the smaller the timestep is, but I have not fully quantified this.It will be necessary to examine how the cadence of the halo sampler should relate to the cadence of the spin temperature / recombinations, as well as the user-defined redshifts in
run_coeval.