2nd Order, Partitioned, and Symplectic ODEs

[ChrisRackauckas]

It would be nice to have a type for 2nd order ODEs

u'' = f(t,y)

for things like Runge-Kutta-Nystrom methods. I know there are a bunch of methods which are specifically designed for these problems. Is there a way to also automatically have them convert to a 1st order ODE?

[mauro3]

Yep, that would be good. Conversion is as usual by doubling the number of variables:
v' = f(t,y); u' = v

[ChrisRackauckas]

oh true, that would be an easy promotion to do. And just double the size of the ODE, with the convention of length(u0) + i is the first derivative of the ith component?

[ChrisRackauckas]

But shouldn't it only save the values and not the derivatives (or optionally save the derivatives as du)? I wonder if there's a good way to make that work. Probably a dispatch on build_solution?

[ChrisRackauckas]

We should get @michakraus in on this discussion.

I think the path for this is to have a type structure here like:

SecondOrderODEProblem -> PartitionedODEProblem

Similarly for symplectic problems where one defines a Hamiltonian

H(p,q) = ... # User has to ensure the symplectic property?

we can have

SymplecticODEProblem -> PartitionedODEProblem

and then for the final promotion

PartitionedODEProblem -> ODEProblem

(Maybe throw in a PartitionedDAEProblem too?)

I believe that this gives a way for GeometricIntegrators.jl to properly plug in at all of the right levels, and then have these problems have promoted versions to make things like DP5() still work as a fallback.

[michakraus]

Regarding symplectic integrators, my take on this is that for the time being the user just specifies the vector field, which can be partitioned or not, but there are no checks on symplecticity or the like. Pretty soon there should be an option to specify also invariants like energy or momentum, so that those can be computed automatically along with the solution of the problem, but again no checks of any kind.
At some point I would like to have the option of just specifying a Lagrangian or Hamiltonian with everything else being automatically computed from that, but this is more of a midterm goal.

Regarding 2nd order ODEs, I haven't really thought about this, yet, but it would make sense to have an infrastructure for this, also without resorting to rewriting it as a system of 1st order ODEs. At last, standard variational integrators are discretisations of 2nd order ODEs...

[ChrisRackauckas]

Regarding symplectic integrators, my take on this is that for the time being the user just specifies the vector field, which can be partitioned or not, but there are no checks on symplecticity or the like. At some point I would like to have the option of just specifying a Lagrangian or Hamiltonian with everything else being automatically computed from that, but this is more of a midterm goal.

This setup of specifying the Hamiltonian/Lagrangian and auto-promoting it to a PartitionedODEProblem is quite easy to do (if we choose a differentiation method like ForwardDiff.jl, but that would add a dependency to DiffEqBase. That's the only problem here), and so PartitionedODEProblem solvers and ODEProblem. And we can easily do the same to change Legrangian systems -> Hamiltonian systems, so a user can specify it whatever level they want.

[Also, the infrastructure of ParameterizedFunctions.jl can easily be adapted to do these computations symbolically. This would take a little bit more work, but would be interesting.]

But from re-reading Hairer II.16, I guess symplectic methods are just methods for PartionedODEProblem which assume a certain structure on the partitioning? If that's the case, then we really just need PartionedODEProblem and the rest of that is just sugar for making PartitionedODEProblems. Right?

[ChrisRackauckas]

Thanks for the inputs. The appropriate problem types were created for solvers. A DiffEqPhysics.jl was created to start a Physics DSL for Hamiltonian and Legrangians. Since the solvers are instead built to PartitionedODEProblems, it's not included in Base but rather will be done separately (and might need differentiation tools)