[newchem-cpp] step_rate_newton_raphson cleanup (1/2)#375
Conversation
The idea is for this struct to aggregate as many arguments for the time derivative as possible. This initial series of patches focuses on aggregating the non-evolved fields
The idea is to collect args that are forwarded to the time-derivative calculation and are effectively frozen between various calls I also converted some of the arguments passed into lookup_cool_rates0d to read from this pack of args. But, I haven't done it for the really large structs (e.g. my_chemistry). I think those will be easier to change later
…s0d from a struct Great effort was made to maintain consistency with historical behavior. Potential issues and ideas for refactoring were highlighted in comments
…ssed to lookup_cool_rate1d
…onsistency that needs to be addressed in the future
The idea is to reduce the number of arguments that we manually pass through
…re no longer needed)
…o gen2024transcribe/step_rate_newton_raphson-cleanup-1of2
step_rate_newton_raphson cleanup (1/2)step_rate_newton_raphson cleanup (1/2)
step_rate_newton_raphson cleanup (1/2)step_rate_newton_raphson cleanup (1/2)
…phson-cleanup-1of2
cf36ad1 to
d750d22
Compare
d750d22 to
10726f8
Compare
| dspj = eps * dsp[idsp[jsp-1]-1]; | ||
| dspj = eps * dsp[idsp[jsp-1]]; | ||
| for (isp = 1; isp<=(nsp); isp++) { | ||
| if(isp == jsp) { | ||
| dsp1[idsp[isp-1]-1] = dsp[idsp[isp-1]-1] + dspj; | ||
| dsp1[idsp[isp-1]] = dsp[idsp[isp-1]] + dspj; | ||
| } else { | ||
| dsp1[idsp[isp-1]-1] = dsp[idsp[isp-1]-1]; | ||
| dsp1[idsp[isp-1]] = dsp[idsp[isp-1]]; |
There was a problem hiding this comment.
Just checking, what's happening here with the removal of the -1s? The for loops are the same, so just want to understand.
There was a problem hiding this comment.
It's related to the fact that the idsp array holds indices.
Prior to this pull request, the idsp array held 1-based indices for accessing (which made sense for Fortran).
A major change in this PR is that we now store 0-based indices in idsp
brittonsmith
left a comment
There was a problem hiding this comment.
This looks pretty good to me, but before merging I'd like to clarify the change to the indexing in step_rate_newton_raphson.hpp and discuss the timestep arguments issue. If it's how you say, then there is an argument to considering this a bug and changing it straight away.
This was originally proposed as brittonsmith#30
This PR must be reviewed after #374 is merged
After PR #374 provided an initial transcription of
step_rate_newton_raphson, this does a bunch of cleanup. Most of the work here was focused on preparations for transcribinglookup_cool_rates0d.Along the way, I discovered a few issues with the logic introduced by the gen2024 PR:
step_rate_newton_raphsondoesn't make sensible choices when it coevolves internal energy with the species anditer !=1gaussj_groutine takes a bunch of code directly from Numerical Recipes. Due to licensing issues, we cannot distribute this code with Grackle