Skip to content

[newchem-cpp] Adjust handling of k27#495

Open
mabruzzo wants to merge 40 commits intograckle-project:newchem-cppfrom
mabruzzo:ncc/k27-treatment
Open

[newchem-cpp] Adjust handling of k27#495
mabruzzo wants to merge 40 commits intograckle-project:newchem-cppfrom
mabruzzo:ncc/k27-treatment

Conversation

@mabruzzo
Copy link
Collaborator

@mabruzzo mabruzzo commented Jan 15, 2026

To be reviewed after #494 has been merged


This PR stops treats k27 more consistently with all of the other reaction rates (radiative or otherwise).

Description

For added context, grackle has historically treated k27 as a special case:

  • At this time, k27 is always the same everywhere (we never model self-shielding and we don't allow users to specify an arbitrary precomputed field).
  • Consequently, we have historically passed around k27 as an unmodified scalar value rather than use a 1D array, like every single other reaction rate known to Grackle

This PR changes this behavior. We now copy k27 into a 1D array.

Tradeoffs:

The benefits pertain to code structure:

  • the control is clearer: all reaction rates are now stored inside of FullRxnRateBuffer and then they are used to update species densities
  • the combination of this change and the change in PR [newchem-cpp] Remove PhotoRxnRateCollection #496 (the followup to this PR, which uses a compile-time LUT to access the photo-rates): all reaction rates will be accessed by index when updating the species
  • (lesser importance) there are slightly fewer arguments getting passed around
  • (lesser importance) this will make creation of a dynamic chemical network easier

The Cost: Grackle is slightly slower. In practice, the performance difference is probably pretty small. When we use k27 (primordial_chemistry>=2), there are at least 30 other reaction rates under consideration. Special handling of 1/30 cases rates is going to have a minimal impact.

Overall, I think this is worth doing. And, if we get to the point where we decide the performance tradeoff isn't worth it, we can always go back to the previous approach later.

Review Advice

This is actually a very simple PR. It's easiest to go through commit-by-commit

ChristopherBignamini and others added 30 commits October 21, 2025 11:02
@mabruzzo mabruzzo marked this pull request as ready for review January 16, 2026 02:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants