HOODESolver.jl is a julia package to solve numerically highly-oscillatory ODE problems. The package is mainly developed by @ymocquar. It implements Uniformly Accurate numerical methods (UA) and works with Big Floats. We try to follow as much as possible the interface defined by DifferentialEquations.jl
This work would not have been possible without the tremendous effort in the organization SciML to share their expertise.
Many thanks to the Julia community
I’m curious, what led to the decision that this is a new “problem”, instead of a new solver for e.g. OrdinaryDiffEq? From the docs I see that you had to introduce a new type of problem HOODEProblem instead of re-using the existing ODEProblem.
Yves was in beginner in Julia when he starts the project. Contribute to a big project like OrdinaryDiffEq is not easy. We would like to improve performance of the package but yes, it could be the next step.
I just read again your question. Perharps you mean we can use ODEProblem instead of HOODEProblem. Yes you’re right, but is it possible to define the right solve function without changing name of the problem struct ?
Yes, there’s more than 10 packages that all define solve dispatches. In fact, every solver in DifferentialEquations.jl is just something that adds a solve dispatch, so you can follow their leads. OrdinaryDiffEq is a big example though, so you might want to look at one of the simpler versions.
It’s documented in:
SimpleDiffEq’s simplest RK4 is probably a good example to follow:
What you’re looking for is a SplitODEProblem where the first part is an AbstractDiffEqOperator so that it’s a linear operator though, which is a little more complex but matches the interface of exponential integrators.
But I think there’s some more ways to co-develop here.
What are the advantages of these matrix exponentials? Could they be added to ExponentialUtilities.jl for use in the other matrix exponential methods? It seems like PolyExp is a Phi function, and the Krylov subspace versions might scale better? This is work digging into.
The advantage of having it as a separate repo is that, well, it already is and it can be simple. The advantage of trying to get this into OrdinaryDiffEq is that it would add event handling. Which is better is up to you. https://github.com/SciML/IRKGaussLegendre.jl is a good example of a solver that has stayed standalone for easier maintenance and citation.
But I forgot to say, this solver is super cool and I’ve been reading through Hairer Geometric and hoping we’d get a method for this exact case. You’re sent from heaven, and I hope to get your work into the ecosystem so I can point more users to it! Thanks for your work.
As suggested by @Datseris and @ChrisRackauckas we offer a common interface with a SplitODEProblem. Since we need to set the value of the epsilon parameter, we define a new operator similar to the DiffEqArrayOperator. We did not find a way to avoid this new type and use an existing one in DifferentialEquations. Get the epsilon value from a DiffEqArrayOperator is not robust. I wrote a simple example here SplitODEProblem · HOODESolver.jl