Non-split physics for all explicit or IMEX time discretisations #578
Conversation
|
|
||
| stepper.run(0, tmax=tmax) | ||
|
|
||
| error = norm(stepper.fields('f') - f_end) / norm(f_end) |
There was a problem hiding this comment.
I don't know if this test is too slack? I think we are mainly testing the transport her and less testing whether the physics is correct.
Could we:
(a) check against the result from a split-physics time stepper (which would have the downside of being inefficient unless we make the split-physics value be a KGO)
or (b) find a coupled physics test with a known solution?
Co-authored-by: Thomas Bendall <[email protected]>
…t/gusto into nonsplit_physics
tommbendall
added
the
research problem
…make correct changes to physics schemes
…st be added. Lint fails..
There was a problem hiding this comment.
This is really thorough, and I really appreciate the extension of the different physics tests. I think the test_nonsplit_physics gives a lot of confidence that this is working correctly.
I'm happy for this to go in -- my only suggestion is whether we want to think about putting the wave equation classes into the rest of Gusto. However this is just up to you, I think it's fine to stay in the test.
| from math import pi | ||
|
|
||
|
|
||
| class WaveEquation(PrognosticEquationSet): |
There was a problem hiding this comment.
Might we actually want this to be an actual equation rather just live in the tests? I'm happy either way but just wanted to suggest it
Currently you can only have physics when using IMEX RK, Explicit RK (Predictor) or IMEX SDC by using SpitPhysicsTimestepper. I will add the capability to do this, and a unit test to show it has the same results as SplitPhysicsTimestepper.