No explicit restriction on SciMLBase to 2.10.0

[jlchan]

Adding this since I encountered it in #2001.

There's no explicit compat restriction on SciMLBase, but v2.50.5 breaks PlotData2D due to the signature of ODESolution changing from 2.10.0

https://github.com/SciML/SciMLBase.jl/blob/84602f38c7aa9423386744532f2ca9478f55535f/src/solutions/ode_solutions.jl#L102-L103

to the following in v2.50.5

https://github.com/SciML/SciMLBase.jl/blob/12f30308a4f4959dd6bbf97efc1f600621546cf4/src/solutions/ode_solutions.jl#L108-L109

I think we are currently restricted to v2.10.0 indirectly by dependence on StartUpDG 0.17.7.

[jlchan]

I added RecursiveArrayTools as an explicit Trixi dependency in #2001 so that I could add a compat bound and avoid this issue. Updating to the new signature should allow us to remove RecursiveArrayTools as a direct dependency as well.

[huiyuxie]

How do you @jlchan plan to resolve this issue? Updating the old signature and removing RecursiveArrayTools would be good for my issue - but does it take a long time?

[jlchan]

@huiyuxie yes, my plan would be to resolve #1789, which should then let us remove restrictions and RecursiveArrayTools. However, I'm not sure how long this will take. I am meeting with some of users of DGMulti next week to figure out what to move around.

If these changes are holding you back, maybe we could create a branch of Trixi (with DGMulti completely removed) that you can base TrixiCUDA.jl on? Maybe @sloede has some better idea too.

[huiyuxie]

Thanks! Let me think - creating a specialized branch might be good, but this is temporary. I will come back to this solver; From my point of view, this is where the most speedup is needed, as it runs slower than other solvers. Will you remove a lot of things from DGMulti @jlchan ?

[jlchan]

Yes, my plan at the moment (tentative plan!) is to remove a significant amount of functionality - mainly the flux differencing solvers for non-collocation DG methods (e.g., where approximation_type=Polynomial and when we use VolumeKernelFluxDifferencing).

These are also some of the solvers that tend to run more slowly, not necessarily because they aren't optimized, but because they involve more operations.

[huiyuxie]

I see thanks for replying @jlchan 👍