-
Notifications
You must be signed in to change notification settings - Fork 153
Upgrade Restart API to OrdinaryDiffEqCore 4 #2773
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
base: main
Are you sure you want to change the base?
Changes from all commits
61e66fe
e1eeb89
78b5903
5a85411
7659188
c52f6b6
84748c8
511122e
3c4662e
055a5a2
21f79e4
db12ed5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,46 @@ | ||
| module TrixiOrdinaryDiffEqCore | ||
|
|
||
| import Trixi: load_controller! | ||
| import OrdinaryDiffEqCore: OrdinaryDiffEqCore, PIController, PIDController | ||
| import HDF5: attributes | ||
|
|
||
| @static if Base.pkgversion(OrdinaryDiffEqCore) >= v"3.4" | ||
| import OrdinaryDiffEqCore: PIControllerCache, PIDControllerCache | ||
| end | ||
|
|
||
| # Support to load controller | ||
| function load_controller!(integrator, controller::PIController, file) | ||
| if !("time_integrator_qold" in keys(attributes(file))) | ||
| error("Missing data in restart file: check the consistency of adaptive time controller with initial setup!") | ||
| end | ||
| integrator.qold = read(attributes(file)["time_integrator_qold"]) | ||
| end | ||
|
|
||
| function load_controller!(integrator, controller::PIDController, file) | ||
| if !("time_integrator_qold" in keys(attributes(file)) || | ||
| !("time_integrator_controller_err" in keys(attributes(file)))) | ||
| error("Missing data in restart file: check the consistency of adaptive time controller with initial setup!") | ||
| end | ||
| integrator.qold = read(attributes(file)["time_integrator_qold"]) | ||
| controller.err[:] = read(attributes(file)["time_integrator_controller_err"]) | ||
| end | ||
|
|
||
| @static if Base.pkgversion(OrdinaryDiffEqCore) >= v"3.4" | ||
| function load_controller!(integrator, controller::PIControllerCache, file) | ||
| if !("time_integrator_qold" in keys(attributes(file))) | ||
| error("Missing data in restart file: check the consistency of adaptive time controller with initial setup!") | ||
| end | ||
| controller.errold = integrator.qold = read(attributes(file)["time_integrator_qold"]) | ||
| end | ||
|
|
||
| function load_controller!(integrator, controller::PIDControllerCache, file) | ||
| if !("time_integrator_qold" in keys(attributes(file)) || | ||
| !("time_integrator_controller_err" in keys(attributes(file)))) | ||
| error("Missing data in restart file: check the consistency of adaptive time controller with initial setup!") | ||
| end | ||
| controller.dt_factor = integrator.qold = read(attributes(file)["time_integrator_qold"]) | ||
| controller.err[:] = read(attributes(file)["time_integrator_controller_err"]) | ||
| end | ||
| end | ||
|
|
||
| end | ||
|
Comment on lines
+3
to
+46
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. TBH: This looks like a nightmare to maintain, especially given rather unpredictable and unreliable actions upstream. Maybe we consider dropping the controller completely from the restart file? Opinions @ranocha ?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
May I ask why? From my perspective this should actually help in terms of adding new controllers in a more reliable way, as you get now a clear error if an unknown controller has been used. It should also be easier now to add custom controllers, as for example done with the PID controller. Also, there are at least plans to drop the old interface with OrdinaryDiffEq v7 to simplify the controller logic and integration, as it became a bit messy over time with the orgrainical growth. And as I said intitially, I would also like to move this upstream into SciML, as I think having some IO mechanism would be beneficial for other frameworks too. What do you think?
I am not sure if that is a good idea tbh. Not loading the controller correctly tanked some of the tests quite badly.
Just my two cents here. Since that is a concern to you, it might be worth communicating to the SciML people what makes their actions so bad, so they have at least the chance to adjust their development processes. I am not sure if they are fully aware of what is going so bad in your case.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Because this essentially requires knowledge of undocumented functionality (which we also use in other parts of the code, which is certainly not ideal)
Hm yes, but that just amounts to fixing some tests.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This was already the case before. Now, after the refactoring of the controller interface, you should be able to just de-/serialize the controller cache object in most cases. Please note that I had to keep the old interface and full compatibility with trying to not break too much downstream codes relying on having access to these fields, like for example Trixi . I try to remove the old interface with the next major release of OrdinaryDiffEq tho. Therefore, in the worst case you can use JLD2 for this instead of relying on the given fields of each cache object. Does that make sense?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for cleaning up the controllers in OrdinaryDiffEq.jl - and for taking your time to update our code accordingly, @termi-official! Did I understand correctly that you plan to implement such a store/load functionality in SciML directly? This would be extremely helpful for us, since it would be tested there and we would not have to maintain it ourselves.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would you be fine with merging this PR, @ranocha (edit: we can do this after the next breaking release though)?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would like to wait with the merge briefly.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, thanks. Let me know when we should proceed with this PR.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The latest release should work out of the box again without the fixes presented here. The new PR is SciML/OrdinaryDiffEq.jl#3038 doing the breaking changes to prepare the OrdinaryDiffEq v7 release (and bumping Core to 4). The fix here will then again be needed to load the controller cache correctly on restart.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for the update! Let's try #2782 then. |
||

Uh oh!
There was an error while loading. Please reload this page.