-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make custom integrators more similar to OrdinaryDiffEq.jl integrators? #1886
Comments
I originally implemented it like it is right now to simplify it as much as possible while keeping the option to use the same functionality we need from integrators provided by OrdinaryDiffEq.jl. I would be fine with these changes but @sloede needs to agree as well (since it makes the implementation more complex). To be able to use custom integrators also for the cases you mentioned, we would need to specialize |
I think if we would really want to use |
But we would also need the same |
IIUC, you do not want to make the implementation much more complicated, but just refactor To some extent, ime integration is black magic anyways, and not that many people need to deal with its nitty gritty details except when they need something special - and in that case, more modularity is probably helpful |
Yes that is right!
I actually think that the more explicit version could even be helpful in illustrating that not the ODE-Algorithm, but actually the ODE-Integrator actually solves the problem |
While looking at the
elixir_euleracoustics_co-rotating_vortex_pair.jl
I noticed that this can only be run with the integrators fromOrdinaryDiffEq.jl
because theEulerAcousticsCouplingCallback
requires astep!
functionTrixi.jl/src/callbacks_step/euler_acoustics_coupling.jl
Line 189 in 18aaae9
and an
init
functionTrixi.jl/src/callbacks_step/euler_acoustics_coupling.jl
Line 129 in 18aaae9
which are not provided by the existing implementations.
We could, however, add these functions relatively easy, exemplified by
SimpleIntegrator2N
:Essentially, we would need to provide a
init
functionthat is essentially the current
solve
function with only the last line changedTrixi.jl/src/time_integration/methods_2N.jl
Lines 108 to 133 in f109695
Then, the
step!
function could be implemented aswhich is almost identical to the current
solve!
functionTrixi.jl/src/time_integration/methods_2N.jl
Lines 135 to 193 in f109695
For the version with
init
andstep
one could then implementsolve
aswhich behaves as before.
The text was updated successfully, but these errors were encountered: