-
Notifications
You must be signed in to change notification settings - Fork 126
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
MRI-adaptivity #564
base: develop
Are you sure you want to change the base?
MRI-adaptivity #564
Conversation
…o feature/mri-adaptivity
…eature/mri-adaptivity
… as its own inner stepper
…o feature/mri-adaptivity
I believe I addressed all requests, and none are visible on GitHub.
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.
Ok finished going through new changes and remaining files
|
||
**Arguments:** | ||
* ``method`` -- the coupling table identifier. | ||
:return value: An :c:type:`MRIStepCoupling` structure if successful. A ``NULL`` |
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.
Minor inconsistency between using :return value:
vs :return:
in the PR
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.
I think that I made these consistent among files that I'd edited in this PR, but if you notice something that I missed, please let me know.
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.
The (undocumented) style used elsewhere is to use :return:
(or :returns:
) when describing what a function returns and :retval <value>:
for a list of error codes. Additionally, .. c:type::
does not work with these directives and generally looks bad (as I think was noted here and in other PRs). I've suggested edits to keep things generally more consistent and future PRs can address updating existing documentation. To help keep the style consistent in the future I've proposed a style guide for function documentation in #588.
test/unit_tests/arkode/CXX_serial/ark_test_accumerror_brusselator.cpp
Outdated
Show resolved
Hide resolved
test/unit_tests/arkode/CXX_serial/ark_test_accumerror_brusselator.cpp
Outdated
Show resolved
Hide resolved
@@ -0,0 +1,611 @@ | |||
/*----------------------------------------------------------------- |
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.
It would be nice to consolidate the common code among this and the other two Brusselator tests (possible a few other places too) into a shared file.
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.
Perhaps, but based on the type of test (slow error, accumulated fast error, MRI adaptivity) I need to put different operators into the various RHS functions, so although the parameters and equations are shared, I worry that a common header file would have too many different permutations of RHS functions, potentially obfuscating what actually differentiates one test from another.
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.
I started a directory (test/unit_test/problems
) for doing this in #501. In that case there is a kpr.hpp
file with different RHS functions for different splittings of the problem and it's used in the logging tests.
@@ -0,0 +1,386 @@ | |||
/* ----------------------------------------------------------------------------- |
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.
I'm concerned about how much code is duplicated here with the corresponding arkstep version. Now that forcing is define at the ARKode level, I think we can have one test file that covers several steppers. I realize that's easier said than done and that it's probably not feasible to do now.
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.
I'll give this some thought, since we might also want to eventually add a unit test for mristepsetforcing. However, I think that for now these can remain separate.
Co-authored-by: Steven Roberts <[email protected]>
…ARK_ERK22b (to match fixed-step default)
Added utility routine to wrap any valid ARKODE integrator for use as an MRIStep | ||
inner stepper object, `ARKodeCreateMRIStepInnerStepper`. |
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.
Added utility routine to wrap any valid ARKODE integrator for use as an MRIStep | |
inner stepper object, `ARKodeCreateMRIStepInnerStepper`. | |
Added a utility routine to wrap any valid ARKODE integrator for use as an MRIStep | |
inner stepper object, `ARKodeCreateMRIStepInnerStepper`. |
Deprecated ARKStep-specific utility routine for wrapping as an MRIStep | ||
inner stepper object, `ARKStepCreateMRIStepInnerStepper`. |
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.
Deprecated ARKStep-specific utility routine for wrapping as an MRIStep | |
inner stepper object, `ARKStepCreateMRIStepInnerStepper`. | |
Deprecated the ARKStep-specific utility routine for wrapping an ARKStep instance | |
as an MRIStep inner stepper object, `ARKStepCreateMRIStepInnerStepper`. Use | |
`ARKodeCreateMRIStepInnerStepper` instead. |
Added utility routine to wrap any valid ARKODE integrator for use as an MRIStep | ||
inner stepper object, :c:func:`ARKodeCreateMRIStepInnerStepper`. |
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.
Added utility routine to wrap any valid ARKODE integrator for use as an MRIStep | |
inner stepper object, :c:func:`ARKodeCreateMRIStepInnerStepper`. | |
Added a utility routine to wrap any valid ARKODE integrator for use as an MRIStep | |
inner stepper object, :c:func:`ARKodeCreateMRIStepInnerStepper`. |
Deprecated ARKStep-specific utility routine for wrapping as an MRIStep | ||
inner stepper object, :c:func:`ARKStepCreateMRIStepInnerStepper`. |
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.
Deprecated ARKStep-specific utility routine for wrapping as an MRIStep | |
inner stepper object, :c:func:`ARKStepCreateMRIStepInnerStepper`. | |
Deprecated the ARKStep-specific utility routine for wrapping an ARKStep instance | |
as an MRIStep inner stepper object, :c:func:`ARKStepCreateMRIStepInnerStepper`. Use | |
:c:func:`ARKodeCreateMRIStepInnerStepper` instead. |
solution are computed by solving an auxiliary ODE with a fast (inner) time | ||
integration method. This corresponds to the following algorithm for a single | ||
step: | ||
For cases with only a single slow right-hand side function (i.e., :math:`f^E |
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.
I took a pass at revising this section to clean up the formatting of the algorithm and add back some of the detail that was removed for IMEX-MRI-GARK methods (e.g., the description of "solve-decoupled") by adding a short subsection for each family. Please add some more detail to the IMEX-MRI-SR and MERK similar to the IMEX-MRI-GARK section (e.g., that some integrations are grouped).
* erkStep_SetInnerForcing is used to provide a polynomial forcing term in | ||
* ERKStep when it is used as the inner integrator under MRIStep. To check that | ||
* the forcing is computed and applied correctly we integrate an ODE in time | ||
* with ERKStep where to RHS consists of only the polynomial forcing term. The |
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.
* with ERKStep where to RHS consists of only the polynomial forcing term. The | |
* with ERKStep where the RHS consists of only the polynomial forcing term. The |
#endif | ||
|
||
/* User-supplied Functions Called by the Solver */ | ||
static int f(realtype t, N_Vector y, N_Vector ydot, void* user_data); |
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.
Update realtype
to sunrealtype
tshift = (realtype)atof(argv[5]); | ||
tscale = (realtype)atof(argv[6]); |
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.
tshift = (realtype)atof(argv[5]); | |
tscale = (realtype)atof(argv[6]); | |
tshift = SUNStrToReal(argv[5]); | |
tscale = SUNStrToReal(argv[6]); |
T0 = (realtype)atof(argv[3]); | ||
Tf = (realtype)atof(argv[4]); |
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.
T0 = (realtype)atof(argv[3]); | |
Tf = (realtype)atof(argv[4]); | |
T0 = SUNStrToReal(argv[3]); | |
Tf = SUNStrToReal(argv[4]); |
|
||
if (argc > 2) | ||
{ | ||
order = (int)atol(argv[2]); |
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.
order = (int)atol(argv[2]); | |
order = atoi(argv[2]); |
I think that this PR is now ready for full review.
Note: I removed all of the changesets that I'd pulled from @Steven-Roberts's PR #547 to simplify the review process for this PR.