-
-
Notifications
You must be signed in to change notification settings - Fork 196
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
Is remake
ing an ODEProblem
with a symbolic map of u0
or p
type-stable?
#2652
Comments
No, no symbolic map will be. That's just not possible. But |
Thanks for answer Chris. Could I ask as well if Or would that call for a more performant but bespoke implementation? More generally, is symbolic indexing in ModelingToolkit/SciMl intended for internal code and performance, or just for interactivity/flexibility (i.e plotting different |
See https://docs.sciml.ai/ModelingToolkit/stable/examples/remake/ and specifically https://docs.sciml.ai/ModelingToolkit/stable/examples/remake/#Re-creating-the-problem for ways in which updating parameters can be done in a tight loop. There are also some type stability improvements in #2613 |
Thanks for the pointers @SebastianM-C , I hadn't seen these docs before. Final question: what is the idiomatic/performant way to access observed variables from an
|
I'd recommend checking out SymbolicIndexingInterface.jl for that. You'd want to save |
I have an
ODEProblem
that is initialized with the types of bothu0
andp
asVector{Float64}
.When I
remake
with the same types, the output of@code_warntype
seems to indicate the compiler knows the type of the returnedODEProblem
:However, when I take advantage of the symbolic indexing, it seems to be unable to infer that the returned
ODEProblem
will still have auType
ofVector{Float64}
uType
of theODEProblem
iswhere _A
here, where previously the concrete typeVector{Float64}
was inferred.remake
s internals, this should be inferrable, as theu0
symbolic map with typeVector{Pair{Symbol, Float64}}
is intercepted and processed into the aVector{Float64}
internally before actual reconstruction of theODEProblem
Am I missing anything or is this a known issue?
I discovered this when profiling my optimization code and seeing a large fraction of runtime dispatches surrounding my objective function, which calls
remake
with a symbolic map.The text was updated successfully, but these errors were encountered: