-
Notifications
You must be signed in to change notification settings - Fork 54
[newchem-cpp] Organize collisional reaction rates into an indexable table #411
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
mabruzzo
wants to merge
48
commits into
grackle-project:newchem-cpp
Choose a base branch
from
mabruzzo:ncc-opaque-storage
base: newchem-cpp
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
[newchem-cpp] Organize collisional reaction rates into an indexable table #411
mabruzzo
wants to merge
48
commits into
grackle-project:newchem-cpp
from
mabruzzo:ncc-opaque-storage
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For context, the historic convention in Grackle project was to use .C as the suffix for C++ source files. Thus, when we began transcribing files, we used the .C suffix (even though it is a less common choice than .cpp) However, it turns out that converting a file named `<prefix>.c` to `<prefix>.C` causes lots of issues performing Git operations when your machine has a case-insensitive file-system (common on macOS). This comes up in operations as simple as changing between 2 branches Consequently, we will be transitioning to the .cpp suffix
A few tweaks were necessary: - I needed to add the `extern "C"` annotation to a number of functions that are publicly exposed as the C API - I removed the leading underscore from some internal helper functions - I needed to tweak make the group name argument passed to initialize_cloudy_data expect a `const char*`, rather than just a `char*`. This is essential since we are passing a string literal (this was a very minimal change) I also added to the `static` specifier to some internal functions (this ensures that these helper functions will not be accessible to external code)
I also renamed initialize_rates.h to initialize_rates.hpp to denote that the header is **ONLY** compatible with C++ source files
…units & internalu.a_value)
…the values directly from my_chemistry)
…le::impl::initialize_metal_chemistry_rates
This information has been formatted into a markdown table (that will be rendered into a table if/when we use doxygen)
… initialize_metal_chemistry_rates.cpp
These docstrings include a lot of context from the comments that were originally in the Fortran rates calculation routines and that were previously copied into initialize_metal_chemistry_rates.cpp (and into initialize_rates, but that is less of a concern right now)
We plan to use `init_reaction_rate` to initialize all of the "ordinary" collisional rates. While I was here, I marked `add_reaction_rate` as `static` (i.e. it isn't used outside of the translation unit corresponding to initialize_rates.cpp)
The code has gotten a lot uglier...
These are now unnecessary. The next step is to actually remove these members from the struct
This was referenced Sep 3, 2025
…tal_chemistry_rates
…tal_chemistry_rates
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR should be reviewed after #378, #401, and #402 are all merged
Importantly, this is all intended as a precursor to transcribing
lookup_cool_rates1d_g
.Overview
The primary purpose of this PR is to move all of the ordinary collisional rates from within
chemistry_data_storage
into a single table-like data-structure.lookup_cool_rates1d_g
), we will be able to convert a lot of the interpolation logic into for-loopsCollisionalRxnRateCollection
struct that previously started using within thesolve_rate_cool
function.gr_opaque_storage
struct. Thechemistry_data_storage
struct holds an opaque pointer to thegr_opaque_storage
struct, and thegr_opaque_storage
struct holds theCollisionalRxnRateCollection
.FILE*
pointer used for IO in the standard C library (likeFILE*
, the definition ofstruct gr_opaque_storage*
is never directly exposed to user-code). The docstrings forgr_opaque_storage
provide additional context.CollisionalRxnRateCollection
pointer inside ofchemistry_data_storage
and avoided defininggr_opaque_storage
entirely. However, I think we will gradually want to migrate more "stuff" inside ofgr_opaque_storage
.Reviewing this PR
It might be easiest to go through this commit-by-commit. All of my changes were very atomic (I tried to make the individual commits fairly descriptive)
Why this is a pre-requisite for transcribing
lookup_cool_rates1d_g
?This is a prerequisite because the transcription machinery will automatically reference the rate tables in their new locations after transcription. It will save us some duplicate work.
Now that I've done all this work (it was far more involved than I expected), it has become obvious to me that the benefits to doing this work before transcribing
lookup_cool_rates1d_g
is actually fairly minimal. (I guess it wasn't obvious to me since its been a while since I last transcribed some routines). In any event, what's done is done