Skip to content

[newchem-cpp] photo-chemical rate functionality needs refactor #449

Description

@brittonsmith

The way we include photo-chemistry rates is becoming unworkable and should probably be refactored as part of newchem-cpp, for reasons I discuss below.

In Grackle main, we support 8 photo-chemical rates (k24-k31) and soon that will include rates for metal ionization/dissociation and HD dissociation as part of newchem-cpp. These are currently supported in several overlapping ways:

  1. UVB tables: k24-k31 are currently set in the UV background tables if a user supplies a redshift-dependent data file.
  2. Manual modification of rate values: we currently allow the user to manually modify k24-k31 in some fashion (although the opaque storage has likely changed this). However, these are clobbered by using a UVB table.
  3. Radiative transfer fields: a subset of the above rates can be passed as full field arrays enabled with the use_radiative_transfer parameter. The behavior is further altered by parameters like radiative_transfer_hydrogen_only and H2_custom_shielding (and in newchem with radiative_transfer_HDI_dissociation, radiative_transfer_metal_ionization, and radiative_transfer_metal_dissociation). There is further complication with newchem-cpp parameters like radiative_transfer_use_H2_shielding, whose unique function I have yet to full appreciate (i.e., this seems to almost duplicate simply turning of H2 self-shielding).
  4. There are even additional bespoke parameters like LWbackground_intensity, which sets only k31, even though Lyman-Werner radiation in reality should effect more reactions (like H- detachment).

As alluded to above, these all combine in different ways. Some are additive to others and some clobber. Just typing it out here I am appreciating how much closer to unworkable we already are.

Features of a workable solution

I am reluctant to propose a full solution to this, mostly because I don't really have one. I think we have largely closed off Option 2 above. Here are things I'd like to see. The ability to:

  • provide any single photo-rate as a field array (e.g., use_RT_k24 (not that I think we should tie ourselves to this rate numbering))
  • provide any singe rate from a model (i.e., a UVB table)
  • combine rates from the above sources
  • alter any rate not coming from radiative transfer internally (e.g., through self-shielding)

Metadata

Metadata

Assignees

No one assigned

    Labels

    refactorinternal reorganization or code simplification with no behavior changes

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Status
    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions