Feature/arkode sts

[maggul]

This is a draft PR for feedback on new STS module.

[drreynolds]

Unfortunately, the rebase to develop seems to have marked hundreds of files as conflicts. I'll work on fixing this branch now, so that it will be easier for folks to review.

[balos1]

Unfortunately, the rebase to develop seems to have marked hundreds of files as conflicts. I'll work on fixing this branch now, so that it will be easier for folks to review.

Yeah, I think in the future we should not rebase develop on main (if main is updated directly) and instead do a merge. I don't see a real advantage to having the same linear history for main and develop, and it seems the rebase has a pretty big downside.

[drreynolds]

and it seems the rebase has a pretty big downside.

Indeed. Although rebasing might be no big deal for branches with 1-2 commits, it is a huge waste of time for a branch with any appreciable amount of development.

[drreynolds]

I still need to look at the changes in src/arkode, but I wanted to share my comments so far.

[drreynolds]

One more set of comments, covering the rest of this draft PR.

[drreynolds]

I've finished reviewing the documentation updates. I'll review the code soon.

[maggul]

I have completed my revision of the PR. @gardner48, thanks for your comments on the RHS evaluations. I’ve found a way to reduce one more line of vectors, which aligns better with our low-storage claim. This new approach involves recomputing fn if the step fails, which should be infrequent, thereby reducing the extra line of vectors that would otherwise be needed to store fn. Please review the updates and let me know if there’s anything else you need me to address. @drreynolds @balos1 @Steven-Roberts

[drreynolds]

I just finished going over the revisions to this PR, and I have a few more minor requests.

[Steven-Roberts]

Are the changes in the .gitlab folder intended?

[Steven-Roberts]

I don't see why the +0.5 is necessary (and in round function below). This macro has the potential to cause undefined behavior if x is greater than the max sunindextype value. If we can avoid the cast that would be ideal, but if not we should document the potential for undefined behavior.

[maggul]

What do you think @drreynolds? Where do you think we should document this behavior?

[drreynolds]

I believe that adding 0.5 is the "standard" trick to ensure that floating-point output from floor is cast to the correct integer.

SUNDIALS has no documentation for our "math" functions, so I do not have a recommendation on where to put it there. I recommend that the comments above (line 329) be updated to mention the danger when casting the output of floor to the nearest sunindextype for arguments that exceed the representable range of sunindextype.

[Steven-Roberts]

I believe that adding 0.5 is the "standard" trick to ensure that floating-point output from floor is cast to the correct integer.

I think this is conflating the standard trick for rounding:

(sunindextype) (x + SUN_RCONST(0.5))

with simply calling round or floor and casting. Since floor is already called, I see no need to for the +0.5.

[maggul]

The round function returns a double, while an int is expected. Casting a double to an int will truncate the decimal part. If round produces a value slightly less than the expected integer, casting will result in an integer that is one less than desired. To avoid this phenomena, we add 0.5 after rounding and before casting.

[drreynolds]

I may be off on this, but if the algorithm to compute the number of required stages for a given step size h and spectral radius rho is updated to do the comparisons/calculations in floating-point arithmetic, and to then only cast the final result to int, do we even need these new integer-valued functions (e.g., SUNIfloor)?

[maggul]

No matter at which stage we do, we have to cast ss to an integer. Can you check the current commit? I think your suggestion will help with limiting ss so that we will not encounter too big integer issues.

[drreynolds]

I like the change. My only recommendation is to use step_mem->req_stages = SUNIceil(ss); so that we are certain to use a "stable" number of stages.

[maggul]

I ceiled the number once on the top to find ss, so ceiling one more time might end up increasing it by one for the same double argument type reasoning. round seemed to be more appropriate option for me.

[drreynolds]

Are the changes in the .gitlab folder intended?

I'm guessing they are not intended. I noticed that after the Gitlab CI PR #595 was merged, my local repository clones showed conflicts that needed to be resolved using

git submodule update --init --recursive

I'm guessing that @maggul may have "resolved" the issue in some other way. @maggul, can you clarify what you did to update feature/arkode-sts with these changes from develop after #595 was merged, since we may need to figure out how to resolve this change correctly?

[balos1]

Are the changes in the .gitlab folder intended?

I'm guessing they are not intended. I noticed that after the Gitlab CI PR #595 was merged, my local repository clones showed conflicts that needed to be resolved using

git submodule update --init --recursive

I'm guessing that @maggul may have "resolved" the issue in some other way. @maggul, can you clarify what you did to update feature/arkode-sts with these changes from develop after #595 was merged, since we may need to figure out how to resolve this change correctly?

@maggul Should just run

git fetch origin
git checkout origin/develop -- .gitlab
git submodule update
git add .gitlab
git commit

and that should fix things.