-
Notifications
You must be signed in to change notification settings - Fork 13
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
Non-split physics for all explicit or IMEX time discretisations #578
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this Alex. I've got two main thoughts:
- is the test demonstrating that the physics is correct?
- the explicit 'predictor' physics isn't what I was expecting so needs checking and testing
|
||
stepper.run(0, tmax=tmax) | ||
|
||
error = norm(stepper.fields('f') - f_end) / norm(f_end) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
…make correct changes to physics schemes
…st be added. Lint fails..
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.