In Grackle, the redshift (specified as a_value) plays 2 distinct roles:
It always used to model the impact of background radiation. Concrete examples include:
the CMB temperature-floor.
Compton cooling off of the CMB.
treatment of the UV background. For primordial_chemistry > 0, the reaction rates are impacted. For primordial_chemistry == 0, both the tabulated heating/cooling rates and tabulated temperature calculations are impacted.
When comoving_coordinates == 1, it’s used to parameterize the conversion factor between a simulation's internal code-units and cgs-units changes over cosmic time.
The narrative documentation is currently not very clear about whether Grackle supports modifying a_value when comoving_coordinates == 0 after Grackle is initialized. This is important since Grackle’s comoving-unit-support is not currently compatible with most comoving coordinate systems.
In fact, I had assumed that Grackle didn't support changing the a_value. But, after looking at the code-base, I now think it does. I think we should:
Make this more clear in the narrative documentation
Maybe add a Pygrackle integration test that explicitly confirms that this behavior works as expected.
In Grackle, the redshift (specified as
a_value) plays 2 distinct roles:primordial_chemistry > 0, the reaction rates are impacted. Forprimordial_chemistry == 0, both the tabulated heating/cooling rates and tabulated temperature calculations are impacted.comoving_coordinates == 1, it’s used to parameterize the conversion factor between a simulation's internal code-units and cgs-units changes over cosmic time.The narrative documentation is currently not very clear about whether Grackle supports modifying
a_valuewhencomoving_coordinates == 0after Grackle is initialized. This is important since Grackle’s comoving-unit-support is not currently compatible with most comoving coordinate systems.In fact, I had assumed that Grackle didn't support changing the
a_value. But, after looking at the code-base, I now think it does. I think we should: