Feature/operator splitting #572
Conversation
| #include <arkode/arkode_sprkstep.h> // SPRKStep provides symplectic partitioned RK methods. | ||
| #include <arkode/arkode_splittingstep.h> // SplittingStep provides operator splitting methods. | ||
| #include <arkode/arkode_forcingstep.h> // ForcingStep provides a forcing method. | ||
| #include <arkode/arkode_mristep.h> // MRIStep provides multirate RK methods. |
There was a problem hiding this comment.
Is there some logic behind moving MRIStep to the end of this list? In the absence of some real reason for doing this, I think that this should retain the chronological ordering, with the new steppers put at the end of the list.
doc/arkode/guide/source/Usage/SplittingStep/SplittingStepCoefficients.rst
Outdated
Show resolved
Hide resolved
| (:numref:`ARKODE.Usage.ARKStep.UserCallable`, | ||
| :numref:`ARKODE.Usage.ERKStep.UserCallable`, | ||
| :numref:`ARKODE.Usage.SplittingStep.UserCallable`, | ||
| :numref:`ARKODE.Usage.ForcingStep.UserCallable`, | ||
| :numref:`ARKODE.Usage.MRIStep.UserCallable`, | ||
| and :numref:`ARKODE.Usage.SPRKStep.UserCallable`) |
There was a problem hiding this comment.
Is there some logic behind inserting the new steppers in the middle of this list? In the absence of some clear justification, I think that this should retain the chronological ordering, with the new steppers put at the end of the list.
| :ref:`ERKStep <ARKODE.Usage.ERKStep>`, :ref:`SPRKStep <ARKODE.Usage.SPRKStep>`, | ||
| :ref:`SplittingStep <ARKODE.Usage.SplittingStep>`, | ||
| :ref:`ForcingStep <ARKODE.Usage.ForcingStep>`, and | ||
| :ref:`MRIStep <ARKODE.Usage.MRIStep>`. |
There was a problem hiding this comment.
Is there some logic behind inserting the new steppers in the middle of this list? In the absence of some clear justification, I think that this should retain the chronological ordering, with the new steppers put at the end of the list, and MRIStep before SPRKStep.
| SPRKStep/index.rst | ||
| SplittingStep/index.rst | ||
| ForcingStep/index.rst | ||
| MRIStep/index.rst |
There was a problem hiding this comment.
Is there some logic behind inserting the new steppers in the middle of this list? In the absence of some clear justification, I think that this should retain the chronological ordering, with the new steppers put at the end of the list, and MRIStep before SPRKStep.
| .. _ARKODE.Mathematics.SplittingStep: | ||
|
|
||
| SplittingStep -- Operator splitting methods | ||
| ================================================ | ||
|
|
There was a problem hiding this comment.
Similar question as elsewhere -- why were the new steppers inserted before MRIStep? As everywhere else, I see no reason to jumble the order. These should be listed chronologically: ARKStep, ERKStep, MRIStep, SPRKStep, SplittingStep/ForcingStep/LSRKStep, ...
There was a problem hiding this comment.
It made sense to group MRI, splitting, and forcing in the docs and I put the new methods first since they are simpler. I can switch to chronological, but I'll note many place put SPRKStep before MRIStep. Should I reorder SPRKStep while I'm at it?
There was a problem hiding this comment.
We can discuss this as a group, but I think that ordering them either chronologically or most-to-least-used would be optimal. In the latter case, we have multiple applications who use ARKStep, and a few who use ERKStep and MRIStep (with more coming). I see no reason to insert new and currently-unused steppers in front, forcing users to scroll down to get to the documentation that they need.
|
In preparation of #587 being merged, I'm wondering how to best count RHS evals. Currently, it can't be accessed through the
I suppose I favor the first option. Anyone else have ideas or preferences? |
I think that you could leave it out entirely, and ARKODE will then return an error that the function is unsupported. If a user creates the SUNStepper components out of SUNDIALS integrators, then they can get the number of RHS evaluations for each component through those directly, and if they provide their own SUNStepper, then they can query that if they want to know what happened internally. |
Ok, that sounds reasonable. On further consideration, my original idea of getting RHS evals from the SUNStepper becomes very complicated if nested partitioning is used. Probably best to avoid that. |
No description provided.