-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generalize Integrator Infrastructure #840
Conversation
I still need to write updated docs, which I have not done yet. |
This now pretty much ready for review. |
Kudos for making this change non-breaking. Only one comment now: isn't the |
Oh yeah that's true---so maybe the |
Simple naming convention, but I would not call classes integrators if they don't do any integration and only contain data |
This is a fair point. I left the name because that's what it was called before I touched it. If others are open to a different naming convention, I can change the name. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, @jonahm-LANL 😸 I don't have too much to contribute... It looks like you mostly covered your bases with unit tests and CI is passing for this PR. More generally, here are some of the thoughts I had regarding your infrastructure and higher order, in general:
(1) Round-off error conservation gets a bit weird with higher order integrators according to the Athena++ community. See this issue: PrincetonUniversity/athena#300. Parthenon may want to address this in the future. As implemented, I predict that higher order integrators with non-exact coefficients will see some departures from conservation.
(2) I was initially thinking about how this PR might influence how one would add a sub-cycling integrator for split physics (e.g., super time stepping). However, I am now not entirely convinced that this infrastructure is what one would use. Instead, I wonder if the solvers infrastructure might instead be the better place for this kind of thing, e.g., for STS:
auto &solver = tr[i].AddSuperTimeStep("RKL1", ...);
auto sts = CreateTaskList(..., i, pmesh, tr, solver, mbase, miter, mout, dt);
Ping one more person: @BenWibking @bprather @brryan @forrestglines @pgrete this PR needs one more approving review to go in. It has been waiting for review for almost six weeks. If I do not see any signs of life by next Monday I will force merge. |
Thanks for the review, @pdmullen ! Regarding your comments:
Yes---I'm sure this is correct. Something to keep an eye on for sure.
Yeah... I haven't thought carefully about this. I tried to make this infrastructure "ready" to extend for such things. But there's definitely questions to answer still as far as that goes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using this in KHARMA and broke nothing. I like making MultiStageDriver a specialization of a new generic version.
I have no way to test the higher-order methods implemented here independently, but the unit tests seem complete.
Thanks @pdmullen @bprather ! We now have two approvals. AthenaPK folks: @forrestglines @pgrete speak now-ish or forever hold your peace on the integrator MR. I'll enable auto-merge on Monday morning. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good and bonus points for the additional documentation.
I just found couple of typos that I just fixed directly.
Thanks @pgrete ! In that case I'm going to pull the trigger. |
PR Summary
I am pushing on high-order methods on parthenon downstream. To prepare for this, I needed some higher-order integrators. For that reason, I've implemented several improvements to our integrator machinery, without breaking any backwards compatibility:
Class hierarchy
I have split the
StagedIntegrator
class into a class hierarchy. The base class contains a little shared functionality. There are currently two subclasses:LowStorageIntegrator
, which contains the family of low-storage integrators used by Athena++ expressed in Shu Osher form. (This is what @pgrete updated our integrators to some time ago.)ButcherIntegrator
which contains a few commonly-used Butcher tableaus plus a 10th order one for fun. The butcher tableau machinery is introduced with IMEX and multi-rate integrators in mind down the line.I also have templated the
MultiStageDriver
class on integrator type, with the default beingLowStorageIntegrator
, which returns to the old machinery. (To prevent people from having to typetemplate<>
when inheriting from theMultiStageDriver
, I name the generic oneMultiStageDriverGeneric
and use a type alias to produceMultiStageDriver
.)The intent here is that if one knows they will be only a specific integration scheme, they should inherit from an iterative driver specialized to that specific integrator. However, the class hierarchy opens the possibility of switching between integration schemes at runtime.
In a similar vein, I have added some functions to
update.hpp
that can take the integrator object and do the update by reading it. I have not updated our examples or any downstream codes to use these functions, so they may have bugs. Nevertheless I'd like to merge them in if possible and fix them later as I work on my high-order machinery. If people object, I can remove them. I have some discussion points about this below.Additional changes:
LowStorageIntegrator
. Forparthenon-hydro
andAthenaPK
this should offer immediate benefits if you want to try it out.Questions
update
functionality to leverage the integrators more easily. However, it's untested. Should we leave it out until I have a test case? Or should we add it now and fix it later after testing?@pgrete your thoughts on this PR in particular will be valuable given you're using the low-storage integrators downstream.
PR Checklist