AayushSabharwal
commented
1 month ago This is not a bug. Notice that the callback function has the signature (u, t, integrator). The state values at the time the callback is triggered are given by u, not the integrator. This is because the integrator will step past the callback, then interpolate backward. The interpolated values are passed as u, and the time that the callback is triggered is given by t. If you print t and integrator.t inside the callback, they won't be the same.
The discrepancy goes away when using numerical indexing in the save_func, like save_func = (u, t, integrator) -> u[1].
Note how you're indexing u here and it works. integrator.u[1] will fail.
jonathanfischer97
Inconsistent Results from Symbolic Indexing in ODESolution vs SavingCallback
There appears to be a discrepancy between the values obtained through symbolic indexing of an
ODEProblemsolution and those saved using aSavingCallbackwith symbolic indexing of the integrator. This occurs when usingSymbolicIndexingInterface.jlwithin the context of solving ODEs withModelingToolkitandDifferentialEquations.Specifically, when solving an ODE system and saving a variable (in this case, 'x') using two different methods:
ODESolutionusingsol[:x]SavingCallbackwithintegrator[:x]The results show a noticeable difference, suggesting that the symbolic indexing within the
SavingCallbackmay not be accurately capturing the state of the system at each time point.Expected behavior
The values saved using the
SavingCallbackwith symbolic indexing (integrator[:x]) should match those obtained directly from theODESolution(sol[:x]) at corresponding time points, as both methods are intended to access the same state variable 'x' throughout the solution process.Minimal Reproducible Example π
This issue suggests a potential problem with how SymbolicIndexingInterface.jl interacts with the integrator object within SavingCallback, possibly related to caching or how the symbolic indexing is resolved during the callback execution.
However, I'm not quite sure and this issue may be better placed under the other packages used here. This might have more to do with
DiffEqCallbacksthan the symbolic indexing. The discrepancy goes away when using numerical indexing in thesave_func, likesave_func = (u, t, integrator) -> u[1].Environment (please complete the following information):
using Pkg; Pkg.status()using Pkg; Pkg.status(; mode = PKGMODE_MANIFEST)versioninfo()