factor step_rate_newton_raphson out of solve_rate_cool_g.F
#10
Conversation
This file contains 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
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
mabruzzo
force-pushed
the
gen2024-step_rate_newton_raphson
branch
from
e26f0cf to
ac1be72
Compare
mabruzzo
changed the title
step_rate_newton_raphson out of solve_rate_cool_g.F
Merged
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 factors the logic for the Newton-Raphson solver out of
solve_rate_cool_g.I decided to name the new routine
step_rate_newton_raphsonsince it is the alternative to the existing Gauss-Seidel scheme,step_rate_g.There were previously some comments in the routine suggesting that you wanted to make this change. Making this change now will definitely help with the process of transcription.
I have confirmed that all tests pass before and after this change.
(This requires #7 to be merged)