Implement revised time stepping schemes

[charleskawczynski]

Purpose

The purpose of this SDI is to implement the SSP IMEX scheme, described in this document. The motivation for implementing this scheme is to maintain bounds-preservation of limited prognostic fields across stages.

Cost/Benefits/Risks

• Cost: 2-3 engineers/scientists for 3-4 weeks
• Benefits: It's expected that this scheme should preserve bounds constraints and (hopefully) improved numerical stability
• Risks: Utilization of time and cost of resources

People and Personnel

(@ the personnel required/requested to implement the software solution)

• Lead: @dennisYatunin and @charleskawczynski
• Collaborators: @Zhengyu-Huang
• Reviewers: @Zhengyu-Huang

Components

Components delivered will include:

• Fix the (currently broken) docs

Imex ARK

• An implementation of a user-facing scheme constructor
• An implementation of ClimaTimeSteppers's step_u! with appropriate caching
• A detailed outline of the notation and scheme in the documentation
• Improve performance (if necessary). If this scheme is more than 30% slower than the existing implementation, we will spend 1 week on investigating and improving performance.

SSP RK

• An implementation of a user-facing scheme constructor
• An implementation of ClimaTimeSteppers's step_u! with appropriate caching
• A detailed outline of the notation and scheme in the documentation
• Improve performance (if necessary). If this scheme is more than 30% slower than the existing implementation, we will spend 1 week on investigating and improving performance.

Open performance issues that should be resolved at a later time

• Performance optimizations, suggested in Optimize out unneeded calls to dss! and lim! #107
• Inference issues found in Fix inference failures in revamped ARS343 #103.
• Inference issues found in Fix flame graph inference #108.

Inputs

N/A

Results and deliverables

See the components section

Task Breakdown And Tentative Due Date

• One PR for detailed documentation including notation and the algorithm (Add background info for ODE solvers #164)
• One PR Several PRs containing implementation of the algorithm, cache and tests (Add sketch for ssprk #109, Add diffusion test problems #148, Add Algorithm Modes #151, Rename "Tableau"s to "AlgorithmName"s #152, Update plotting analysis #157, Add Deformational Flow Example #161)

Proposed Delivery Date

December 14th January 27th

---

CC

@cmbengue @tapios

[tapios]

What about this should take 3-4 weeks? The straightforward implementation should not take long. Are you concerned about performance?

[charleskawczynski]

What about this should take 3-4 weeks? The straightforward implementation should not take long. Are you concerned about performance?

I think the 3-4 weeks takes several things into account:

• We need to carefully converge on the notation in the code and documentation, to ensure that there's a clear mapping between the documentation and algorithms
• We need to (or, there's great benefit to) extend the existing design, which adds some (but not excessive) friction to leverage already-engineered solutions (e.g., custom/generic stopping criteria, compatibility with OrdinaryDiffEq, leveraging existing CI / docs infra and tests).
• We need to convert, to some extent, the google document into documentation in the code
• We need to implement the algorithm, a (simple) caching structure
• We need to get the resulting code running, i.e., fix bugs in the algorithm / caching structure after our first draft
• Add tests (this should be fairly straight forward to extend), and time to fix issues that arise when running unit tests
• We'll want to test this in ClimaAtmos, before merging, to make sure that we can demonstrate that the algorithm works in at least a simple example.

I'm not concerned about performance. At the moment, we're going to do the bare minimum for the implementation, and we'll only work on performance if we see it as an issue in the first ClimaAtmos tests.

[tapios]

Ok. Tests we already have for all standard cases. You may just need to re-tool tests for limiters (incorporating @valeriabarra's tests).

Daniel and I can help with notation in the doc. Just let us know what you need. This is straightforward, as is making it code documentation when it's done.

How about we first get the code working (e.g., the revamped ARK_IMEX--it should be a straightforward replacement of what we have, with small changes when there are limiters)? Finish this, merge it, test it (with existing tests, first without limiters), and then move on. I want to avoid a situation in which this leads to overengineering before we test the simplest cases.

[trontrytel]

From our discussion today: Possible test cases could be: gravity waves, sound wave on a sphere, diffusion.

[tapios]

From our discussion today: Possible test cases could be: gravity waves, sound wave on a sphere, diffusion.

@charleskawczynski and I talked some more about this. It'll be better to have simpler test cases, which do not require an atmosphere model yet exercise the full functionality of the timesteppers. There are good tests in ARKode, including some that are multivariate (e.g., 1.13 and 1.14 in http://runge.math.smu.edu/ARKode_example.pdf).

[charleskawczynski]

Updates:

• Imex ARK is now complete, merged in #85

Related PRs:

• Update to new ClimaTimeSteppers ClimaAtmos.jl#1179
• Refactor ode init ClimaAtmos.jl#1196
• Prep benchmarks script for CTS revamp ClimaAtmos.jl#1185
• Refactor ode init ClimaAtmos.jl#1193
• Refactor ODE initialization ClimaAtmos.jl#1190
• Update to new ClimaTimeSteppers ClimaAtmos.jl#1179
• Refactor ode init ClimaAtmos.jl#1177

@OsKnoth, can you please comment on this issue and summarize the issue we faced, and fixed, in this commit? Just so that we have a public record

[charleskawczynski]

Next we have:

• Delete old (and unused) time steppers (Remove old code, update docs, add explicit algs #166 )
• Add more unit tests, (e.g., 1.13 and 1.14 in http://runge.math.smu.edu/ARKode_example.pdf)
• Add SSP algorithm, described in the google doc