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
Solve seems to miss timesteps specified by PresetTimeCallbacks #805
Comments
The latter won't be more efficient here. The former is going to be better. For performance, it would more sense to encode those values as parameters and then flip the parameters
I double checked the details here: function affect!(integrator)
@show integrator.t, itp_q_in(integrator.t)
@show integrator.u[3]
integrator.u[3] = itp_q_in(integrator.t)
integrator.u[4] = itp_X_in(integrator.t)
integrator.u[5] = itp_Y_in(integrator.t)
end
cb = PresetTimeCallback(inputArray[:,1], affect!, save_positions=(false, false))
# %% Solve ODE, plot results
sol = solve(prob, Tsit5(), callback=cb)
using Plots
plot(sol)
The values that are supposed to be going to zero are clearly going to zero, and the callback is triggering at all of the times from the CSV. That all checks out as correct to me. The fact that |
function affect!(integrator)
ind_t = findall(t -> t==integrator.t, dosetimes)
@show integrator.t, inputArray[ind_t[1], 2]
global q_in = inputArray[ind_t[1], 2]
global X_in = inputArray[ind_t[1], 3]
global Y_in = inputArray[ind_t[1], 4]
end
cb = PresetTimeCallback(dosetimes, affect!, save_positions=(false, false))
sol = solve(prob, Tsit5(), callback=cb)
You can see that the two dosing schemes are not the same. The interpolation gives: |
Dear Chris, thanks for looking into this. I found that when I add a very small number to The reason I went with |
DataInterpolations.jl won't have the round-off issue as it will be exact at the data points. As for performance, I don't know. |
I am trying to implement feeding pulses in the right-hand side of an ODE system. Let's say times and values are stored in a CSV file called
Inputarray_Odm2prod_2h_3d.csv
:The following code works, but is quite inelegant and inefficient:
with the resulting plot:
Since I wanted to take advantage of some advanced features of ModelingToolkit.jl, I recoded the model into this version (using Interpolations.jl), which is supposed to do the same, but more efficient:
As one can clearly see,
q_in
is never reset to 0 between feedings, so it accumulates over time, giving a completely wrong result:But evaluating
itp_q_in
at the specified times interactively gives the correct result! So I am not sure where the error is here. Is it in my code, or some of the involved libraries? Maybe something about tolerances!?Or maybe there is a better way to implement this whole approach, which avoids this issue!?
The text was updated successfully, but these errors were encountered: