Open daviehh opened 2 months ago
Yeah, it looks like extract_local_sensitivities
only uses the sensealg
in the problem construction, inside of sol.prob.problem_type.sensealg
. It also seems like adjoint_sensitivities
also ignores sensealg
inside of the solve
call.
@jClugstor did you ever get around to this?
Not yet, but should be an easy fix, I'll look at it this week.
Question: if both solve and the problem definition have sensealg, which one to respect?
solve
.
I'm not actually sure this is possible without having the kwargs to solve being part of the solution object.
why would that be the case? It's in the prob and only called forward.
If you call extract_local_sensitivities(s_sol, 4.0)
and s_sol
doesn't have information on what sensealg
was used in solve
,
extract_local_sensitivities
can't use the solve
sensealg. extract_local_sensitivities
already uses the sensealg
from s_sol.prob
.
Describe the bug 🐞
The
sensealg
in solve is ignored, currently it only follows the sensealg defined in the problemLooks like, the sensealg is not in the prob.kwargs, and is ignored in the solve_up call
https://github.com/SciML/DiffEqBase.jl/blob/6b1191f2993f163f09e8b718b28599ac1b3f16e3/src/solve.jl#L993-L1007
https://github.com/SciML/DiffEqBase.jl/blob/6b1191f2993f163f09e8b718b28599ac1b3f16e3/src/solve.jl#L1066-L1083
Expected behavior
allow the sensealg in solve to work
Minimal Reproducible Example 👇
Error & Stacktrace ⚠️
A and B gives same result, different from C, or,
s_sol = solve(s_prob, Tsit5(), sensealg=1)
would actually run without any error messages.Environment (please complete the following information):
using Pkg; Pkg.status()
using Pkg; Pkg.status(; mode = PKGMODE_MANIFEST)
versioninfo()
Additional context
The last example at https://docs.sciml.ai/SciMLSensitivity/stable/tutorials/direct_sensitivity/ uses the sensealg in the solve call, might be confusing