Skip to content

SUNDIALS interface updates #4562

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

Open
wants to merge 22 commits into
base: development
Choose a base branch
from

Conversation

gardner48
Copy link
Contributor

Summary

  • Check SUNDIALS return flags
  • Abort if a required callback function is called but not set
  • Fix selecting a specific IMEX method with SUNDIALS
  • Document time integrator runtime inputs
  • Read base class parameters at construction
  • Add options for selecting the algebraic solvers with implicit methods
  • Add option to set a stop time
  • Only output settings and final statistics with verbose output is enabled

Additional background

Various fixes and enhancements from testing methods in FerroX

Checklist

The proposed changes:

  • fix a bug or incorrect behavior in AMReX
  • add new capabilities to AMReX
  • changes answers in the test suite to more than roundoff level
  • are likely to significantly affect the results of downstream AMReX users
  • include documentation in the code and/or rst files, if appropriate

@gardner48
Copy link
Contributor Author

FYI @ajnonaka, various updates I made when testing with FerroX. I'll open a PR with some corresponding updates on the FerroX side as well.

@@ -17,8 +17,8 @@ to :cpp:`amrex::Initialize` and the function adds parameters to AMReX's
.. important:: AMReX reserves the following prefixes in :cpp:`ParmParse`
parameters: ``amr``, ``amrex``, ``blprofiler``, ``device``,
``DistributionMapping``, ``eb2``, ``fab``, ``fabarray``,
``geometry``, ``particles``, ``tiny_profiler``, and
Copy link
Contributor

Choose a reason for hiding this comment

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

Could the prefix used be time_integration rather than integration? this would be more consistent with the object and folder naming. If this would require invasive changes elsewhere it's not required

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

Successfully merging this pull request may close these issues.

2 participants