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

Runge-Kutta-Legendre stabilised explicit method #1673

Merged
merged 12 commits into from
May 13, 2019
Merged

Conversation

bendudson
Copy link
Contributor

@bendudson bendudson commented Apr 10, 2019

Uses Strang splitting (2nd order) to combine:

  • RK3-SSP for advection (3rd order)
  • Runge-Kutta-Legendre for diffusion (2nd order). These schemes uses multiple stages to increase stability, rather than accuracy; this is always 2nd order, but their stable timestep for diffusion problems increases as the square of the number of stages. The number of stages is an input option, can be arbitrarily large.

See https://doi.org/10.1016/j.jcp.2013.08.021

To try it out, set solver:type=splitrk. Use options solver:timestep to set the internal timestep, and solver:nstages to set the number of stages in the RKL method.

Explicit method, adaptive time stepping by default, checking accuracy a specified number of timesteps.

Tested by eye with a few examples, passes the unit and MMS tests. So far not particularly useful for real cases, but probably good enough to include.

Note that the MMS/time test has been modified to test both the convective and diffusive parts. This shows that Karniadakis converges at 1st order. I think we should remove that method, as there are better options (such as this).

Uses Strang splitting (2nd order), with RK3-SSP for the advection
parts, and Runge-Kutta-Legendre for the diffusion. This method can
take timesteps considerably larger than a standard explicit scheme
can for diffusive problems.
- Some changes to ensure that Arrays were always unique without having
  to reallocate.

- Updated the IMEX/drift-wave and IMEX/advection-diffusion examples
@bendudson bendudson added work in progress Not ready for merging feature labels Apr 10, 2019
@d7919
Copy link
Member

d7919 commented Apr 10, 2019

Looks interesting!

If a physics model is not split into convective and diffusive parts,
should it be treated as convective or diffusive?

Previous behaviour was to treat as diffusive. This switch keeps this
default, but allows it to be changed.
Apparently I can't do mental arithmetic, so coefficients were off
by a factor of 2 (and wrong sign in some cases...).

Caught thanks to `test-solver`. Thanks @ZedThree!
Modify the MMS/time test so that it has non-zero convective
and diffusive parts.

This reduces the Karniadakis convergence order to 1, since it uses
an Euler method for the diffusion part. Probably should remove this
solver as there are better options.

SplitRK converging at expected 2nd order.
Doesn't yet seem to work well, or at least is taking a lot more steps
than should probably be necessary.
Large increases in timestep generally overshoot and result in reductions later.
In some tests the timestep was oscillating between extremes.
The default now limits changes in timestep to a factor of 2 (up or down).
@bendudson bendudson removed the work in progress Not ready for merging label Apr 28, 2019
Describes the options and includes links to paper describing the RKL
method.
@@ -459,6 +459,9 @@ private:
/// Diffusive part (if split operator)
rhsfunc phys_diff{nullptr};

/// Should unsplit physics models be treated as diffusive?
bool unsplit_diffusive{true};
Copy link
Member

Choose a reason for hiding this comment

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

How do you feel about is_unsplit_diffusive, or even is_nonsplit_model_diffusive?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes happy with either of those. Maybe is_nonsplit_model_diffusive is clearer?

ZedThree
ZedThree previously approved these changes May 9, 2019
Codacy complaining about variable `neq` not initialised in
constructor. This initialises `neq` and other similar variables.
@ZedThree ZedThree merged commit 30de389 into next May 13, 2019
@ZedThree ZedThree deleted the solver-split-rk branch May 13, 2019 08:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants