Gen2024 rank errors#11
Merged
brittonsmith merged 17 commits intoDec 18, 2024
Merged
Conversation
This patch converts nearly all usages of the ``logical`` type to the
newly defined ``MASK_TYPE`` in the Fortran source files throughout
Grackle.
- The ``MASK_TYPE`` type is a custom datatype that just wraps a 32bit
integer.
- Because Fortran will not implicitly cast between logicals and
integers we need to explicitly compare this value against
``MASK_TRUE`` and ``MASK_FALSE``.
- For consistency with C semantics, if-statements that want to see
if the mask is true always compare ``MASK_TYPE`` value is not equal
to ``MASK_FALSE``.
- The **only** ``logical`` variable that wasn't changed was the
``end_int`` variable that we pass into ``interpolate_3Dz_g``.
We haven't touched this variable to avoid interfering with existing
efforts to transcribe that function to C/C++
- This patch is extremely similar in spirit to GH PR
grackle-project#227. But there a fewer minor distinctions:
- I am actually more confident in the correctness of this patch (I used
custom tools to automate the majority of these changes)
- I converted more variables in this patch (that other PR **only**
changed the ``itmask`` variable).
I have explicitly confirmed that all tests continue to pass after the
introduction of this PR
The `cool1d_multi_g` subroutine expects an argument `iter`. Previously, the `cool_multi_time_g` subroutine would pass a value of 1 directly to this argument. To simplify the process of transcription, we now store the value inside of a local variable called `dummy_iter_arg` (if we didn't do this, we would need to insert logic into our transcription routine to inject a custom variable to hold the value of 1 and then pass a pointer to that value into `cool1d_multi_g`).
I made some minor tweaks to where we pass in the pointers to the i-dimension of grid_dimensions, grid_start, and grid_end. This is a purely superficial change, but will allow automated transcription to produce better code.
…ate_newton_raphson_v2
Tests seem to be passed!
…(these are used internally by step_rate_newton_raphson)
… step_rate_newton_raphson.F
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`).
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
To be reviewed after #10
This simply fixes a few spots with array-rank issues:
h2dustSaandh2dustCavariables were declared as 2D variables in some spots and declared as 1D variables in another spotstep_rate_newton_raphsonpassedisrf_habingas an array to a function that was expecting a scalarcool_multi_time_gdeclaredregrato be a scalar even though it is actually a 1D array