-
Notifications
You must be signed in to change notification settings - Fork 35
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
Support running VL+CT Integrator as a single stage integrator #315
Support running VL+CT Integrator as a single stage integrator #315
Conversation
…ing the hydro equations over the course of a timestep
…oMHDVlctIntegrator (and other stuff related to B-fields).
…to EnzoMHDVlctIntegrator.
Also improved the documentation of the class.
…structor to source file
85dabf1
to
0680a46
Compare
Changes introduced in PR enzo-project#315 make it unnecessary for individual classes in the hydro-infrastructure to have PUP routines. Instead of directly serializing the individual classes, the changes introduced in that PR direct the solver to serialize the parameters used to configure the solver, and then reconstructs all of the component classes after a restart. This simplifies things quite a bit. This commit sheds the now-unnecessary PUP routines.
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 -- clearly commented.
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.
Thank you very much for this addition! It is structured well and heavily commented. I'm approving and merging.
Oops, no merging yet. @mabruzzo Can you resolve the merge conflict and then we can merge after it passes the tests (again). |
Overview
This PR is long-overdue.
Actual Changes
To accomplish these goals, this PR does the following:
EnzoMHDIntegratorStageCommands
class, which encapsulates all of the functionality that is necessary to update hydro/mhd quantities over an individual stage (the number of stages per timestep depends on the time-integration strategy). This class was necessary since theEnzoMethodMHDVlct
class was starting to do too much (and becoming hard to understand). In detail:EnzoMethodMHDVlct::compute
intoEnzoMHDIntegratorStageCommands::compute_update_stage
.compute_flux_
andcompute_source_terms_
, as well as a bunch of attributes fromEnzoMethodMHDVlct
toEnzoMHDIntegratorStageCommands
.EnzoMethodMHDVlct
's constructor and ``EnzoMethodMHDVlct::timestepover to
EnzoMHDIntegratorStageCommands` (I'm less sure that these were optimal choices).EnzoMHDIntegratorStageCommands
is ignorant of how the stages in the MHD/Hydro integrator are linked together. That's handled byEnzoMethodMHDVlct
. TheMethod
class also tries to take most of the responsibility for interfacing with the rest of Enzo-EMethod:mhd_vlct:half_dt_reconstruct_method
andMethod:mhd_vlct:full_dt_reconstruct_method
parameters. The former only existed due to an oversight on my part (it never made any sense for this to exist - the VL+CT scheme doesn't work unless nearest-neighbor reconstruction is used). The latter is replaced by the newMethod:mhd_vlct:reconstruct_method
. Backwards compatibility has been maintained.Method:mhd_vlct:time_scheme
method to choose the time integration method. Right now, it defaults to"vl"
(the predictor-corrector scheme) and the only other choice is"euler"
(the simpler 1-stage integrator for testing purposes). In the future, this could be extended to accept other choices (e.g. for a Runge-Kutta integrator).PR Dependency
This PR unfortunately needed to build on changes from PR #302 (there would have been too many merge conflicts) and this probably can't be reviewed until that PR is merged (it should be merged soon - just waiting on a reviewer to hit approve after I made their requested changes). I will update this PR when it's readyEDIT: This is now ready for review.