support scimlbase 3#1171
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1171 +/- ##
=======================================
Coverage 90.04% 90.04%
=======================================
Files 136 136
Lines 10595 10595
=======================================
Hits 9540 9540
Misses 1055 1055
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
/run-gpu-tests |
|
/run-gpu-tests |
|
This PR breaks compatibility with all old versions. Do we want that? Trixi.jl keeps backwards compatibility: |
yes but they don't actually test the old stack. I tried with an older version before and than it just broke because of the dependencies that are too wide in the sciml world. |
|
So if we want to have compatability with the older sciml stack we would also need to add a test in my opinion for that. |
|
That is a good point. I guess since we're not as big as Trixi, we can simply drop support for the old versions. @sloede what do you say is the best approach here? |
# Conflicts: # Project.toml # src/callbacks/sorting.jl # src/callbacks/split_integration.jl # test/Project.toml # test/examples/examples_fluid.jl
I don't think backwards compatibility is strictly needed. If you find that for some reason SciMLBase v3 is not working out, you can always re-add backwards compatibility later. |
|
|
||
| # Tell OrdinaryDiffEq that u has not been modified | ||
| u_modified!(integrator, false) | ||
| # This callback only reports progress and does not introduce a derivative discontinuity. |
There was a problem hiding this comment.
I think this is not very self-explanatory. How about something like this?
| # This callback only reports progress and does not introduce a derivative discontinuity. | |
| # This callback only reports progress and does not change the result of the right-hand side. |
This comment is for all occurrences of derivative_discontinuity!.
| # Usually, `u` is modified in the split integration above, but if the split | ||
| # integrator has already been advanced to the new step time in the last stage of the | ||
| # previous step, the split integration above is skipped and `u` is not modified. | ||
| # (Technically, the split integration `u` is copied to the large `u` to account for | ||
| # potential caching errors, but the RHS of the last stage of the previous step | ||
| # can be reused for FSAL methods, which is what `u_modified!` is for.) |
There was a problem hiding this comment.
This comment was essential. How about rephrasing it?
# Usually, `u` is modified in the split integration above, but if the split
# integrator has already been advanced to the new step time in the last stage of the
# previous step, the split integration above is skipped and only the split integration `u`
# is copied to the large `u` to account for potential caching errors.
# This does not affect the RHS of the large integrator, so no discontinuity is introduced.3 participants
No description provided.