Discussing Grackle's unit invariants

[mabruzzo]

Overview

Recent discussions have made it clear that we (the core grackle developers) are not exactly sure whether grackle is compatible with any comoving unit system other than Enzo's comoving unit system.

• I have created this issue so that we can resolve these Grackle's unit-system requirements.
• Most of the contents of this issue are adapted from notes I took a while back.
• As I mentioned on the user/developer call I believe that there are strong requirements on the values of the code_units struct (essentially, an Enzo-like comoving unit system is explicitly required). I would really like to refactor Grackle to more strongly enforce these requirements.

Anybody who sees this is strongly encouraged to contribute to this discussion (ESPECIALLY if you have experience integrating Grackle into simulations with other unit systems!)

Throughout this issue, $LU$, $TU$, and $DU$ represent the conversion factor between code_units and cgs units (at a given $a$) for Length, Time, and Density, respectively.

The Invariants

As I understand it, the primary requirements for defining a unit-system compatible with Grackle stem from assumptions made about the units for the quantities computed during initialize_chemistry_data (or local_initialize_chemistry_data). Essentially, grackle requires that the multiplicative factor that must be multiplied by each of the internal quantities, to convert from code-units to cgs units, is constant with respect to cosmological scale factor.

To simplify things I will posit that a_units should be constant with respect to time. I am not sure if that is strictly required (but I suspect it probably is). Furthermore, I don't think that varying this provides the required flexibility to support other unit systems.

Based on contents of the initialize_rates function (and the fact that we explicitly define velocity units as $VU = LU/(TU \times a)$ ), I believe we have 3(ish) invariants:

1. We require the cooling units to remain constant (with respect to $a$): $${\rm const} = \left(\frac{LU}{TU\ a}\right)^2 \frac{m_H^2}{DU\ a^3\ TU}$$
2. We require that non-radiative rate coefficients for 2-body reactions are constant (with respect to $a$): $${\rm const} = \frac{m_H}{DU\ a^3\ TU}$$
   3. We require that non-radiative rate coefficients for 3-body reactions are constant (with respect to $a$): $${\rm const} = \frac{m_H^2}{DU\ a^6\ TU}$$
3. The radiative transfer coefficients are constant (with respect to $a$): $${\rm const} = \frac{1}{TU}$$ I'm least confident about this last invariant. With that said, the constraints it places are redundant with the others

Consequences of the invariants:

Let's assume that the above invariants are correct.

• Combining invariants 2 & 3 reveal that:
  • time units, $TU$, can NEVER change! They must remain equal to the initial choice
  • density units, $DU$, must exactly obey: $DU(a) = DU(a{\rm init}) a{\rm init}^3/ a^3$
• Combining invariants 1 & 2, along with the fact that $TU$ can NEVER change, reveals that the length units, $LU$, must exactly obey $LU(a) = LU(a{\rm init}) a / a{\rm init}$

This means that Grackle provides no flexibility with defining the code_units struct. In other words, at the contents of the code_units struct are precisely specified by the current a_value and the contents of the code_units struct that was passed to initialize_chemistry_data (or local_initialize_chemistry_data).

Discussion Points:

I guess there are 3 main points for discussion:

1. does anybody disagree with (or have concerns about) the conclusions I have drawn from the enumerated invariants?
2. Does anybody disagree with (or have concerns about) the enumerated invariants themselves.
   • Based on conversations with @brittonsmith, I'm very confident that invariant 1 is true
   • I'm a little less sure about the other invariants. They basically assume that Grackle directly uses the reaction rate values without trying to perform additional conversions. (I haven't actually looked at the code)

[brittonsmith]

After reading this over again more carefully, I agree that all items 1-4 should be invariant and consequently, LU, DU, and TU should behave just as you describe. I'm also willing to take it as a given that a_units should never change. I noticed a couple typos that I only mention since this issue may be very useful to refer back to in the future:

• I think item 3 should be "3 body", not "2 body"
• velocity units is missing a factor of a, it should be VU = LU / (TU * a)

I think, despite my previous comments about other comoving unit systems in use in various simulation codes, there are probably very few implementations of grackle that are actually using comoving units in their grackle calls. All the ones I've seen are converting everything to proper first.

[mabruzzo]

Good catch. I fixed those typos. I might try to modify some the documentation to include this point.

I think, despite my previous comments about other comoving unit systems in use in various simulation codes, there are probably very few implementations of grackle that are actually using comoving units in their grackle calls. All the ones I've seen are converting everything to proper first.

To add to that, I recently learned that Cholla is definitely converting to proper units for the Grackle Calls.