Update to OrdinaryDiffEq.jl v7 and related SciML packages

[github-actions]

This pull request changes the compat entry for the RecursiveArrayTools package from 3.37 to 3.37, 4.
This keeps the compat entries for earlier versions.

Note: I have not tested your package with this new compat entry.
It is your responsibility to make sure that your package tests pass before you merge this pull request.

Closes #2918, closes #2919, closes #2949, closes #2950, closes #2960, closes #2961, closes #2962, closes #2963, closes #2965, closes #2966, closes #2967, closes #2968, closes #2969, closes #2970, closes #2971, closes #2972, closes #2973, closes #2981, closes #2983, closes #2984.

Also closes #2938 and closes #2941.

The required changes, which keep backwards compatibility with older versions from the SciML ecosystem are:

• Replacing u_modified! by derivative_discontinuity!. Done in Replace u_modified! by derivative_discontinuity! #2996.
• Stage limiters are not allowed anymore as positional arguments, but need to be keyword arguments. Done in Make stage_limiter! a kwarg #2995.
• thread is now passed as FastBroadcast.Serial()/FastBroadcast.Threaded() instead of True()/False(). Done in Implement Trixi.Threaded() #3003.
• Changing a few sol.destats to sol.stats (sol.destats is already deprecated from some time and we changed almost all occurrences already in follow SciMLBase update destats -> stats #1372). Done in Replace deprecated destats by stats #2994.
• Adapting the new controller interface for loading and saving the controller (now in an extension for OrdinaryDiffEqCore.jl)
• The PIDController constructor, which only accepts beta1, beta2, beta3, has (accidentally) another default value for (the algorithm dependent) qsteady_max. We can go back to the previous behavior by also passing the ode algorithm to the constructor of the PIDController. See below for a discussion about this. Edit: This was fixed in OrdinaryDiffEqCore.jl v4.2 and is thus not necessary anymore.
• Changing a reference value due to Fix spurious tiny final step for fixed-dt methods SciML/OrdinaryDiffEq.jl#3441
• Iterating over a VectorOfArray of SVectors now returns the underlying floating values, not the SVector, fixed by replacing u by parent(u)

Note that I used Claude to help me with refactoring some parts, but I reviewed the code and adapted it.

[codecov]

Codecov Report

❌ Patch coverage is 48.14815% with 28 lines in your changes missing coverage. Please review.
✅ Project coverage is 97.04%. Comparing base (bc1048b) to head (7a7d2d8).

Files with missing lines	Patch %	Lines
ext/TrixiOrdinaryDiffEqCoreExt.jl	33.33%	24 Missing ⚠️
src/callbacks_step/save_restart.jl	63.64%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2910      +/-   ##
==========================================
- Coverage   97.09%   97.04%   -0.05%     
==========================================
  Files         630      631       +1     
  Lines       48855    48898      +43     
==========================================
+ Hits        47435    47450      +15     
- Misses       1420     1448      +28     

Flag	Coverage Δ
unittests	97.04% <48.15%> (-0.05%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[JoshuaLampert]

Needs dependencies like SummationByPartsOperators.jl to be updated first.

[JoshuaLampert]

We need jlchan/StartUpDG.jl#219 to be merged and released before.

[ChrisRackauckas]

I think I missed a bit of this, but good to see tests passing. From what I'm gathering, you're asking for an IO API? It would be good for ya'll to start it because you know your needs.

https://docs.sciml.ai/DiffEqDocs/stable/features/io/ is pretty much all we got, but I want to do more because large disk-based adjoints will need it anyways.

But, it's hard to know what exactly is needed here so please share your internal APIs and such as starting points.

[termi-official]

hard to know what exactly is needed here [...]

The TLDR is that we want to store/load the integrators for very long running tasks.

Will write up more details in a separate thread.

[ranocha]

Thanks a lot, @JoshuaLampert and everybody involved in making this possible!

[ranocha]

Did something change in StructArrays.jl?

https://github.com/trixi-framework/Trixi.jl/actions/runs/26215678791/job/77137297189?pr=2910#step:7:12470

[JoshuaLampert]

Did something change in StructArrays.jl?

trixi-framework/Trixi.jl/actions/runs/26215678791/job/77137297189?pr=2910#step:7:12470

There hasn't been a new release from StructArrays.jl recently. The errors looks like they come from #2956. I guess, the changes from there need to be adapted to v4 of RecursiveArrayTools.jl. I'll take a closer look.

[ranocha]

Great, thanks a lot! And sorry for merging the other PR first so that you have even more work...

[JoshuaLampert]

I think 0a26d4b should be the correct fix for this, but can you double-check this makes sense? This fixes the issue locally for me, is consistent with the wrap_array overload for DGMulti, and returns a plain array (in contrast to the VectorOfArray from before) as it should:

Trixi.jl/src/solvers/dg.jl

Line 1217 in 1648f58

# Like `wrap_array`, but guarantees to return a plain `Array`, which can be better

Before, it fell back to use

Trixi.jl/src/solvers/dgmulti/dg.jl

Line 167 in 1648f58

wrap_array_native(u_ode, mesh::DGMultiMesh, equations, dg::DGMulti, cache) = u_ode

.

[JoshuaLampert]

Unfortunately, this is breaking for TrixiAtmo.jl...

[JoshuaLampert]

To make this PR simpler and not breaking, I reverted the changes to wrap_array_native for DGMulti from before and only patched compute_kinetic_energy_spectrum to be compatible with RecursiveArrayTools.jl v4. However, as far as I understand, it would be cleaner if wrap_array_native returns the underlying StructArray instead of the wrapped VectorOfArray around that. If this is something we want, we can do that in another (breaking) PR though.

[JoshuaLampert]

We have the failing subcell tests again, @bennibolm: https://github.com/trixi-framework/Trixi.jl/actions/runs/26223287942/job/77163592740?pr=2910#step:7:7931.

[ranocha]

Thanks a lot!