Open wenflo opened 4 weeks ago
While the error message is a little misleading and should be fixed, this isn't a bug. In the first ("not working") system, S_sep_out2
is an unknown and needs an initial value, which can't be calculated given just the defaults and observed in the system:
julia> sys_simplified = structural_simplify(sys)
Model sys with 1 equations
Unknowns (1):
S_sep_out2(t)
Parameters (2):
S_in [defaults to 1]
q_in [defaults to 1]
julia> observed(sys_simplified)
5-element Vector{Equation}:
S(t) ~ q_in
q(t) ~ S_in
q_sep_out2(t) ~ 0.5
S_sep_out1(t) ~ S_sep_out2(t)
q_sep_out1(t) ~ -q_sep_out2(t) + q(t)
Since S_sep_out2
doesn't have a guess, it can't be solved for during initialization either. Providing the guess works:
julia> prob = ODEProblem(sys_simplified, [], (0, 1); guesses = [S_sep_out2 => 0.1])
ODEProblem with uType Vector{Float64} and tType Int64. In-place: true
timespan: (0, 1)
u0: 1-element Vector{Float64}:
0.0
julia> sol = solve(prob, Rodas5())
┌ Warning: Rosenbrock methods on equations without differential states do not bound the error on interpolations.
└ @ OrdinaryDiffEqCore ~/Julia/SciML/OrdinaryDiffEq.jl/lib/OrdinaryDiffEqCore/src/solve.jl:108
retcode: Success
Interpolation: specialized 4rd order "free" stiffness-aware interpolation
t: 8-element Vector{Float64}:
0.0
1.0e-6
1.1e-5
0.00011099999999999999
0.0011109999999999998
0.011110999999999996
0.11111099999999996
1.0
u: 8-element Vector{Vector{Float64}}:
[1.0]
[1.0]
[1.0]
[1.0]
[1.0]
[1.0]
[1.0]
[1.0]
The solution is constant because this is a system of nonlinear equations, not a DAE/ODE; there are no differential equations.
As for your "working" example, structural_simplify
can analytically solve the system and thus you end up with one that has zero unknowns:
julia> sys_simplified = structural_simplify(sys)
Model sys with 0 equations
Unknowns (0):
Parameters (2):
S_in [defaults to 1]
q_in [defaults to 1]
And creating the ODEProblem
works, because there are no unknowns that need an initial value.
Thanks a lot for the quick and detailed reply! It is very helpful and makes sense to me.
Indeed the error message is misleading (especially also since the wrong variable is mentioned, S_sep_out1
while S_sep_out2
needs the guess). But knowing this, I could fix this issue in the larger problem as well.
However, now, I'm running into another problem, and this is that the simulation seems to get stuck in the initialization (takes over 1h and I put in a progress printing callback which gets never called until then). I'm still working on it to make a MWE and might come back if I manage to create one.
But a general question regarding guesses: Can it be a problem if too many guesses are provided? Or are the additional (for variables removed during simplification) just ignored?
Too many guesses shouldn't be a problem. As for the infinite loop, I fixed an infinite loop in Symbolics@6.15.4. Does updating to that version (or later) help?
I just updated and tested now with ModelingToolkit@9.49.0 and Symbolics@6.16.0 and I'm still facing the infinite loop. Now, however, once I canceled now after ~20min it showed an InitialFailure
response code. I continue on trying to produce an MWE and come back to you once I have it (or a reason why it occurred)
Ok nevermind. It seems that I just selected especially bad initial guesses which apparently made solving the initialization system taking a very long time (~30min, thus before it was most likely indeed the one you fixed in Symbolics and now it was just taking a very long time). Picking better initial conditions now yielded a faster response and a physically sensible result.
Thanks a lot for your help! Shall I close this issue then?
long time (~30min, thus before it was most likely indeed the one you fixed in Symbolics and now it was just taking a very long time
That's probably the maxiters on the recursion detection. 30 minutes would be too high 😅, we should probably make the maxiters a bit lower.
I agree that this is a very long time. But I guess this depends on the number (and size) of loops that are there.
I work with a system that has ~450 unknowns after simplification and in there are 6 loops which are interconnected. +1 additional loop over all of these 6 together. So I guess I have quite some loops involved here :sweat_smile: (Although only few of them are algebraic, I guess the only case where substitutions are involved)
I guess how many iterations there are made, depends on how the maxiters are implemented: if they are applied to all substitutions together (i.e. it is an absolute limit on substitutions) or per-iteration (i.e. limit on applying the same substitution circle, thus in each iteration of the outer loop it could make maxiters iterations on the inner ones).
Describe the bug 🐞
Building an ODEProblem from an ODESystem throws an error indicating missing variables, that were optimized away during
structural_simplify
. By manually combining two of the equations, I can get it to work it for the MWE below.Expected behavior
Building the ODEProblem should work no matter how the equations are specified.
Minimal Reproducible Example 👇
Failing version:
Working version:
Error & Stacktrace ⚠️
Environment (please complete the following information):
using Pkg; Pkg.status()
using Pkg; Pkg.status(; mode = PKGMODE_MANIFEST)
versioninfo()
Additional context
I'm currently working on a library building on top of ModelingToolkit which aims to simulate biochemical reactions (especially for wastewater treatment). Applying it to one of these plants, this error occurred (in a much more complex model). Doing the rewriting myself would not be feasible due to the complexity of the overall model.