Skip to content
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

Finalize Gen PR #177

Draft
wants to merge 190 commits into
base: main
Choose a base branch
from
Draft

Conversation

brittonsmith
Copy link
Contributor

@brittonsmith brittonsmith commented Mar 1, 2024

This is a reissue of PR #143 (originally PR #78). I am going to try to push this forward to getting merged.

To-dos:

  • Extraneous files: remove or move to separate PR
  • Fix latest merger conflic
  • Get everything working with pygrackle
  • Update documentation
  • Add testing

I will shortly be soliciting volunteers to help with this.

mabruzzo and others added 24 commits December 17, 2024 12:21
…(these are used internally by step_rate_newton_raphson)
Previously, it was declared as a scalar.

I was tipped off to this issue by the fact that `cool1d_multi_g`
expected a 1D array. I further confirmed that `solve_rate_cool_g` was
passed the exact same array (by checking arg lists within
`calculate_cooling_time.c` and `solve_chemistry.c`).
Convert `logical` to `MASK_TYPE` (aka `integer*4`)
factor `step_rate_newton_raphson` out of `solve_rate_cool_g.F`
We needed to pass `iH2shieldcustom` and `f_shield_custom` as arguments
to `lookup_cool_rates1d_g`. These variables already had type
declarations within `lookup_cool_rates1d_g`, but they because they were
passed as part of the argument list, they were previously locally
allocated within the function and used without initialization. This is
all fixed now
Cells at low temperatures previously exceeded the iteration limit. This
change should ensure that the tests produce consistent results.
Add logic to initialize itmask_tmp when primordial_chemistry==0. The
need for doing this was identified from running cooling_cell.py
This is done to ease transcription
This was done to remove a bunch of `int(<arg>, 8)` casts. These removed
casts all occured while passing arguments to `interpolate_Nd_g`
routines. Essentially, the Fortran compiler understands that we want to
cast an argument and then pass the result into the subroutine by
reference. This is tricky to transcribe to C/C++.
Prior to this commit, the `chemistry_data_storage` struct declared a 9
attributes for each species ``s``, in the list: ``H2``, ``HD``, ``CI``,
``CII``, ``OI``, ``CO``, ``OH``, ``H2O``. In particular the declaration
looked like:

```c++
{
  long long *Ls_N, Ls_Size;
  double *Ls_D, *Ls_T, *Ls_H, Ls_dD, Ls_dT, Ls_dH, *Ls_L;
}
```

This commit replaced the set of 9 attributes for each species with a
struct called ``gr_interp_grid``. This provides a few benefits:
1. we have removed 64 members from ``chemistry_data_storage``
   (this alone is probably enough reason for the change simplicity is
   better in this complex data structure)
2. we are able to standardize the logic for zero-initializing the data
   in the replaced attributes and for freeing any associated memory
3. this will reduce the code we will eventually need to expose this
   information through the pygrackle interface
4. after transcribing Fortran to C, this will help with encapsulating
   some common operations.

> [!NOTE]
> Technically, most members of ``gr_interp_grid`` are sorted into a
> separate struct called ``gr_interp_grid_props``. The provided comments
> explain that this lays the groundwork for reducing duplication with
> the ``cloudy_data`` struct at some point in the future.

Even if we decide to reorganize this data in the future, it will be easy
to transform it from the new version of the code than it would be before
this commit.
Prior to this commit, there was a collection of 9 members in the
`chemistry_data_storage` struct. This commit replaced those 9 members
with a single member of type `gr_interp_grid`.
Basically, I factored out all of the common code for each
`initialize_cooling_rate_{s}` function (this function exists for
each member of `chemistry_data_storage` that stores a `gr_interp_grid`
struct).
@mabruzzo
Copy link
Collaborator

mabruzzo commented Jan 5, 2025

I just wanted to share some quick thoughts that I had while working on this branch.

I think we need to make sure we address the following 2 points (or have a concrete plan to address them) before we merge this PR:

  1. We had discussed disabling dust chemistry with primordial_chemistry==0. I do think its extremely important that we make sure that we have support photoelectric heating with primordial_chemistry==0 (I'm not sure if this will actually be an issue or not).1

  2. I am extremely hesitant to add dust temperatures to the grackle_field_data struct. It is extremely inconsistent with how we handle other derived quantities (i.e. pressure, temperature, cooling_time) and how we have historically handled dust_temperature.

    • I guess I am concerned that we are doing something a little permanent.
    • Do we have a sense for how much people actually compute dust temperatures?
    • I think I would rather see us introduce a separate experimental function that use instead for this sort of thing (before we lock into a permanent modification to the API)

Footnotes

  1. Aside: I actually think that re-enabling dust temperature calculations with primordial_chemistry == 0 may be easier than I once thought.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants