Solution interface - what's missing?

[thomvet]

Cool package, could be useful in my area once it's more mature.

I would be willing to help out to some extent. A good start (in the sense of immediately useful) maybe be to have the SciML solution interface implemented.

Is it already in the works or, if not, are there any pointers to how to do it? I am asking before I dig into the code too much. As I said - I'd be willing to help out 😄

[termi-official]

Hi Thomas, thanks for reaching out! The package really needs quite a bit more love until its mature. But I am happy to see that it is, at least in principle, also useful for others!

The solution interface is currently about 0% done, as I have no clue on how exactly to implement it yet. As you are probably aware is a central issue how to keep the solutions to the "subproblems" in sync with the "full" solution, as the solutions to the subproblems are discontinuous at the endpoints of each time interval. Maybe @oscardssmith has an idea where to start?

[oscardssmith]

I think the approach here is likely to use interpolation of the sub-solutions to move the timesteps to be synchronized.

[termi-official]

use interpolation of the sub-solutions

The problem is that the sub-solutions, in general, do not have sufficient information to interpolate the "full" solution correctly.

[oscardssmith]

what I was thinking was that the sub-solutions would interpolate their variables, and the top level would put them all together. I guess the tricky part is that variables are shared between different sub-solutions?

[termi-official]

Yea. Unfortunately simply interpolating the sub-solutions will lead to a corrupted interpolation at top level, because the shared variables are not correctly handled. Also, for higher order splitting the interpolation of the sub-integrators at the "time nodes" (e.g. t_n +dt_n/2 for Strang-Marchuk) is not even unique, because the solution of one of the sub-integrators is not continuous at this point. The same goes for all endpoints.

[termi-official]

Probably the easiest way to do this would be to redo the initialization in this package to use a modified variant of the initialization in OrdinaryDiffEqCore. For this we would need to refactor OrdinaryDiffEqCore.__init first to avoid unnecessary code duplication between both packages (and hence to ease the maintenance burden). We can then also try to switch from the custom integrator to the standard OrdinaryDiffEqCore integrator. Does that make sense as a roadmap or do you need the solution interface soon-ish?

[oscardssmith]

seems reasonable to me.

[oameye]

This package would also be immensely useful for my research. Probably needs coordination but I am also happy to contribute.

[termi-official]

The next step would be to upgrade to the new OrdinaryDiffEqCore and to kick out the redundancies. The idea so far is that only the outermost integrator carries the solution object, where the inner solution dummys only communicate the failure of a subintegration. Please note that the new version is bit picked up in the CI yet. Due to a broken hand I won't have time to program much by myself for the next weeks, so feel free to pick up the task here if you feel comfortable.