Skip to content
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

Open
wants to merge 142 commits into
base: develop
Choose a base branch
from
Open

MRI-adaptivity #564

wants to merge 142 commits into from

Conversation

drreynolds
Copy link
Collaborator

@drreynolds drreynolds commented Sep 5, 2024

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.

drreynolds and others added 30 commits July 24, 2024 16:34
@drreynolds drreynolds dismissed balos1’s stale review October 1, 2024 18:39

I believe I addressed all requests, and none are visible on GitHub.

Copy link
Collaborator

@Steven-Roberts Steven-Roberts left a 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

doc/arkode/guide/source/Usage/MRIStep/MRIStepCoupling.rst Outdated Show resolved Hide resolved

**Arguments:**
* ``method`` -- the coupling table identifier.
:return value: An :c:type:`MRIStepCoupling` structure if successful. A ``NULL``
Copy link
Collaborator

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

Copy link
Collaborator Author

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.

Copy link
Member

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.

include/arkode/arkode_mristep.h Outdated Show resolved Hide resolved
include/arkode/arkode_mristep.h Show resolved Hide resolved
@@ -0,0 +1,611 @@
/*-----------------------------------------------------------------
Copy link
Collaborator

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.

Copy link
Collaborator Author

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.

Copy link
Member

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 @@
/* -----------------------------------------------------------------------------
Copy link
Collaborator

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.

Copy link
Collaborator Author

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.

Comment on lines +36 to +37
Added utility routine to wrap any valid ARKODE integrator for use as an MRIStep
inner stepper object, `ARKodeCreateMRIStepInnerStepper`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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`.

Comment on lines +64 to +65
Deprecated ARKStep-specific utility routine for wrapping as an MRIStep
inner stepper object, `ARKStepCreateMRIStepInnerStepper`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Comment on lines +33 to +34
Added utility routine to wrap any valid ARKODE integrator for use as an MRIStep
inner stepper object, :c:func:`ARKodeCreateMRIStepInnerStepper`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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`.

Comment on lines +61 to +62
Deprecated ARKStep-specific utility routine for wrapping as an MRIStep
inner stepper object, :c:func:`ARKStepCreateMRIStepInnerStepper`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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
Copy link
Member

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* 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);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update realtype to sunrealtype

Comment on lines 130 to 131
tshift = (realtype)atof(argv[5]);
tscale = (realtype)atof(argv[6]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
tshift = (realtype)atof(argv[5]);
tscale = (realtype)atof(argv[6]);
tshift = SUNStrToReal(argv[5]);
tscale = SUNStrToReal(argv[6]);

Comment on lines 114 to 115
T0 = (realtype)atof(argv[3]);
Tf = (realtype)atof(argv[4]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
order = (int)atol(argv[2]);
order = atoi(argv[2]);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants