# DifferentialEquations.jl change\_t\_via\_interpolation! without save\_everystep for large, expensive ODE

**URL:** <https://discourse.julialang.org/t/differentialequations-jl-change-t-via-interpolation-without-save-everystep-for-large-expensive-ode/104482>\
**Category:** General Usage\
**Tags:** question, diffeq, interpolations\
**Created:** [October 2, 2023, 12:04am UTC](https://discourse.julialang.org/t/differentialequations-jl-change-t-via-interpolation-without-save-everystep-for-large-expensive-ode/104482 "2023-10-02T00:04:45Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![anicusan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/anicusan/32/30094_2.png) [@anicusan](https://discourse.julialang.org/u/anicusan)\
**Post date:** [October 2, 2023, 12:04am UTC](https://discourse.julialang.org/t/differentialequations-jl-change-t-via-interpolation-without-save-everystep-for-large-expensive-ode/104482/1 "2023-10-02T00:04:45Z")

</div>

Hi all,

I am writing a domain-specific simulator built on top of DifferentialEquations.jl; I am solving a mathematically simple, but large / expensive system of ODEs (\>10,000), and wish to minimise memory usage by setting `save_everystep=false` and periodically exporting some data to disk.

With no exporting to disk and using the SciML `integrator` interface, a simulation can finish in 27 function evaluations (as shown by `integrator.stats`); however, adding the periodic saving increases that to 603 function evaluations, both using `DiffEqCallbacks` or explicitly `step!(integrator, next_export_time, true)`. I also set `u_modified!(integrator, false)` to avoid unnecessary saves as there are no discontinuities added.

Would it make sense to do each `step!(integrator)` - i.e. take the maximal successful time step - then use `change_t_via_interpolation!` to “go back” to each data-exporting timepoint between `integrator.tprev` and `integrator.t`? Do the ODE higher-order interpolants apply when `save_everystep=false`, but just between `t` and `tprev`?

I implemented this “maximal stepping, then back-interpolating” (though it’s quite a bit of code; I’m hoping this post is enough to spot any problems with the general approach, but if an MWE is needed please let me know) - however, the calls to `change_t_via_interpolation!` seem to destroy the integration accuracy in future timesteps. In other words, incrementally interpolating between `tprev` and `t` using `change_t_via_interpolation!` does not return the integrator to `t`. Is that expected, and is there a smarter way to let the integrator take maximal steps (and minimise function evaluations) while interpolating intra-step to export some data? I know interpolating can take some time, but I expect it to be much less than running more function evaluations.

Thanks,  
Leonard

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [October 2, 2023, 1:14am UTC](https://discourse.julialang.org/t/differentialequations-jl-change-t-via-interpolation-without-save-everystep-for-large-expensive-ode/104482/2 "2023-10-02T01:14:15Z")

</div>

> [@anicusan](#):
>
> With no exporting to disk and using the SciML `integrator` interface, a simulation can finish in 27 function evaluations (as shown by `integrator.stats`); however, adding the periodic saving increases that to 603 function evaluations, both using `DiffEqCallbacks` or explicitly `step!(integrator, next_export_time, true)`. I also set `u_modified!(integrator, false)` to avoid unnecessary saves as there are no discontinuities added.

If you are using the interpolation to build the save values, there are 0 new function evaluations for any method that’s not a lazy interpolation (i.e. a Verner method).

> [@anicusan](#):
>
> Would it make sense to do each `step!(integrator)` - i.e. take the maximal successful time step - then use `change_t_via_interpolation!` to “go back” to each data-exporting timepoint between `integrator.tprev` and `integrator.t`?

No, just use `integrator(t)` and get it for free.

> [@anicusan](#):
>
> Do the ODE higher-order interpolants apply when `save_everystep=false`, but just between `t` and `tprev`?

Yes, even if the post-solution interpolation is not turned on, the current solution interpolation is always built because it’s free.

> [@anicusan](#):
>
> however, the calls to `change_t_via_interpolation!` seem to destroy the integration accuracy in future timesteps

It would increase the integration accuracy because it’s effectively just decreasing `dt`. If that difference is too large, then your tolerance is too large 😅.

> [@anicusan](#):
>
> In other words, incrementally interpolating between `tprev` and `t` using `change_t_via_interpolation!` does not return the integrator to `t`.

That’s not expected. An ODE that does this? Do you have an MWE?