SciML
MTKv10 discussion
This issue is meant to track and discuss points of action and potential breaking changes for a future MTKv10 release
- Make
@namedalways wrap symbolic arguments inParentScope, so they can be passed multiple levels down the hierarchy. This will need more consideration after identifying which tests break upon making this change. - Discuss
completesemantics - Enforce the
u0mapargument only contains variables, andpmaponly parameters. Discretes will need an exception here.
- Remove the find/replace stuff in
expand_connections. This is only used for MTKStdlib's implementation ofAnalysisPointbut that is moved to MTK as of #3285.
I'd like to discuss making the syntax
Component(inner_par = outer_par)
Introduce a parameter dependence instead of a "dependent default". I find the current behavior is almost never what I want. In modelica, this syntax introduces the equivalent of a parameter dependence.
More generally, support for redeclarstion and modification like https://specification.modelica.org/master/inheritance-modification-and-redeclaration.html (and also JSML) would be very welcome.
Possible changes to field names in symbolic metadata:
vartypebecomingvariable_source- new field
variable_type(corresponding to the MTK variable type)
^ This specifically refers to the NamedTuple returned from get_variable_metadata
Other discussions worth having:
- defaults are now just soft constraints that are only respected sometimes. Especially for parameters since they have to opt-in to initialization.
- Not relying on variable metadata as much. This refers to multiple things
@mtkmodelmacro using it for keeping track of defaults- More importantly,
structural_simplifyusing it to figure out what is a parameter and what isn't.ODESystemcan use the metadata to do this, butstructural_simplifyshould respect whatever bucket we put it in.
Discuss
completesemantics
Should complete() be changed to use flatten = false by default? I find it undesireable that the current default flatten = true destroys the hierarchical model structure without me explicitly requesting it. There are some bugs with flatten = false, though (https://github.com/SciML/ModelingToolkit.jl/issues/3322).
More importantly,
structural_simplifyusing it to figure out what is a parameter and what isn't. ODESystem can use the metadata to do this, butstructural_simplifyshould respect whatever bucket we put it in.
I always thought it could be simpler to have just the @variables macro, and that it should be sufficient to write
@variables t # instead of @independent_variables
vars = @variables x(t)
pars = @variables P # instead of @parameters
eqs = [...]
@named sys = ODESystem(eqs, t, vars, pars)
because it should be clear from the arguments to ODESystem what the independent variable, unknowns and parameters are. Maybe this breaks stuff with the "convenience dispatch" ODESystem(eqs, t) and the @mtkmodel macro (which I have less experience with), or causes other problems, though. This is not a huge deal in practice, though, and I apologize if this is very naive suggestion 😅
Maybe this breaks stuff with the "convenience dispatch" ODESystem(eqs, t)
It doesn't break stuff, but it makes catching user errors more difficult. Maybe they accidentally create @variables x intending it to be an unknown?
the
@mtkmodelmacro
@mtkmodel does its own parsing (something I strongly dislike) so that wouldn't be an issue
or causes other problems, though.
It causes problems for NonlinearSystem, for example, where @variables x could just as well be a parameter as an unknown without the metadata.
https://github.com/SciML/ModelingToolkit.jl/pull/3335#issuecomment-2597825918
defaults are now just soft constraints that are only respected sometimes.
But they are always enforced at the start of a solve?
More importantly, structural_simplify using it to figure out what is a parameter and what isn't. ODESystem can use the metadata to do this, but structural_simplify should respect whatever bucket we put it in.
yes, because otherwise it couldn't handle D(x) ~ 0 turning into a parameter.
https://github.com/SciML/ModelingToolkit.jl/issues/3444#issuecomment-2712081409
Would it make sense to have Initials and other things that might be introduced by MTK in full_parameters and keep parameters for the user specified ones?
Not really, because "user specified ones" is somewhat undefined anyways. If you do D(x) ~ 0, then structural simplify should eliminate x as a part of the state and instead make it a parameter and not solve it, right? While that's not done right now, that's one that clearly should be shown. That's only a start too, if we start to integrate the analytical solvers which we are planning to do, other promotions to parameters would be there as well. In which case, it's not clear the user would just want the "user specified ones", but instead the things that are captured as parameters.
Sure, but in that case can't we export full_parameters and add more options to that? It seems intuitive (to me) that parameters would be the most narrow set and then full_parameters has several kwargs that allow you to see more of the promoted or automatically added ones.
If you do D(x) ~ 0, then structural simplify should eliminate x as a part of the state and instead make it a parameter and not solve it, right?
we rely on x being kept in the state in this case in a lot of places. We might change x externally using the integrator interface, or generate a control function for a state estimator that estimates x from data etc.
x changing in a callback is just a discrete-time state value but is kept internally in MTK as a parameter of sorts. We can know from symbolic callbacks whether it should be treated as discrete-time or constant, and the user can set it as irreducible if it's doing something odd only in function callbacks.
Should we take the opportunity to change names that have been poorly chosen? Like
structural_simplify->simplify_structureorstructural_simplificationso it sounds like English, ormtkbuildto align with@mtkbuildgenerate_xxx / build_xxx-> a consistent choice of one of them
Generate functions and build functions are different and consistent. Generates give the symbolic version of the mathematical object while builds give you the instantiable object
generate did a somewhat weird thing of returning an RGF compiled in Symbolics if you pass expression = Val{false}. This doesn't use our eval_expression and expression_module stuff, and requires splatting MTKParameters to use. In #3543 I've made it so that passing expression = Val{false} to generate_* functions returns a compiled function respecting eval_expression etc. and callable without splatting. This also improves *Function constructor code.
We could collapse build and generate functions if we just make that difference based on expression. That's a reasonable unification with other parts of the interface.
- Make
@namedalways wrap symbolic arguments inParentScope, so they can be passed multiple levels down the hierarchy.
Great, it would be able to propagate the structure parameters down multiple levels, like @mtkbuild sys = Rc(; Rc__Resistor__ConditionalHeatPort__useHeatPort=true, Rc__B__C__D__structureParam2=false), or other ways. https://github.com/SciML/ModelingToolkit.jl/issues/2848#issuecomment-2412912254 @AayushSabharwal
- Expose
tearing_substitute_exprunder a better name - it basically substitutes observed equations into an expression and is a useful utility.
