-
-
Notifications
You must be signed in to change notification settings - Fork 210
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
Cannot create problems with tuple vector variables #3280
Comments
I'm not sure this is supported? Dictionaries and things that transform to dictionaries are supported. Tuples of pairs I guess could work, we'd need to add it to |
I think Tuples have always been supported, right? For parameters I think they are even required for when you have different types in your values. Right now I don't think it is a thing for variables, but seems weird to specifically disallow it here (especially as it might even be useful for hybrid ODE/Jump systems) |
No, the parameters always uses an MTKParameters so it always constructs a different type-stable object and has a representation independent of the user code there. That's a requirement in general in order to support things like non-tunables. |
Tuples were supported in MTK as a way to preserve the type of parameters for years. Then a breaking change was made that upconverted everything to floats in a non-breaking MTK8 release (but tuples were still supported as mappings). Catalyst has used tuple mappings forever because we needed mixed parameter types long before MTK9. There doesn’t seem to be any indication that MTK9 dropped tuple mapping support in the NEWS.md? |
It's a part of the change to MTKParameters. But there's no reason to not support it, we might as well just convert it to a vector since that's always faster, and it would be faster for the user to just give a vector but we might as well collect general collections. |
Wait this is for |
Not sure if they get converted to arrays or something internally, but we probably support hundreds of cases of tuple u0_tup = (X => [1.0, 2.0]) E.g. if the values are scalar that has always been fine, and it has worked over all problem types, using defaults, |
We do not support tuples. We have a specific error message about this and we've had that since 2020, see: SciML/DifferentialEquations.jl#566 The semantics on |
I am not sure about DiffEq, but Tuples have worked in MTK since forever, e.g. using OrdinaryDiffEq, ModelingToolkit
using ModelingToolkit: t_nounits as t, D_nounits as D
@parameters p d
@variables X(t) Y(t)
eqs = [
D(X) ~ p - d * X,
D(Y) ~ p - d * Y,
]
@mtkbuild sys = ODESystem(eqs, t)
u0 = (X => 1.0, Y => 2.0)
tspan = (0.0, 100.0)
p = (p => 1.0, d => 2.0)
prob = ODEProblem(sys, u0, tspan, p)
sol = solve(prob) There are also some test cases: https://github.com/SciML/ModelingToolkit.jl/blob/master/test/sciml_problem_inputs.jl Like, I don't think |
Yes but that's clearly a bug though since the julia> prob = ODEProblem(sys, u0, tspan, p)
ODEProblem with uType Vector{Float64} and tType Float64. In-place: true
timespan: (0.0, 100.0)
u0: 2-element Vector{Float64}:
1.0
2.0 some implicit |
Yeah, my comment above was in reference to parameter tuples. For But it might be better to explicitly disallow it for |
Probably holds for other problem types as well
The text was updated successfully, but these errors were encountered: