Open dannys4 opened 3 years ago
@cadojo @JTaets @jonniedie @baggepinnen @MuradTroll @ronisbr Pinging some people who had thoughts on control systems in prior issues
Hm, is there anything wrong with requiring a structurally simplified system to use features like output equations?
Maybe instead of a hard requirement, we could simply search the observed equations for the outputs with each output jacobian call, and if there's no match, throw an error.
Most users could simply call structural simplify, and the output equations would be automatically found.
If for some reason a user doesn't want to call structural simplify, then they could specify the output equations in the observed
keyword argument in the system constructor.
Those are my knee-jerk reactions anyways!
The problem we were coming across is more like, what if a user has y
decorated as output, then makes it implicit in the system (let's say they have equation y = f(u,p,t,y)
included). You can call structural_simplify
, but that probably won't help, and there's no way you're getting any output jacobian even after calling structural_simplify
. What's a person to do?
Couldn't you test for this and throw an exception that the ODESystem
can not be converted into an explicit form?
From a control engineering perspective it would be nice if one could test if the ODESystem
is already a linear StateSpace
model, a NonlinearStateSpace
or AffineStateSpace
model, similar to what Mathematica provides. And convert between them.
This would also be a nice entry point for other packages that provide automatic controller tuning or other classical control approaches.
We're trying to work toward a more robust support in the vein of linear state systems for the control engineering users. However, you can kind of do this already using Symbolics.islinear
-- it's currently just a little bit delicate (hence the need to iron out these input/output issues).
Oh, cool. I see isafine
is also there.
Maybe it is more intuitive to specify the inputs and outputs when you actually want to compute the Jacobians. If you get an ODESystem
from a Package e.g. JuliaSim
you can not alter the variables of the predefined components, can you?
I guess you could always make a top level model in which you specify the inputs and outputs.
I've not come across a control system description, where the output is given implicitly (someone might correct me on this). I would personally throw an exception too, but there might be certain applications outside of controls that depend on such implicit output models y = f(u,p,t,y)
.
I've not come across a control system description, where the output is given implicitly (someone might correct me on this).
I agree, if the output has its own dynamics then it's typically a state for control systems. Are output dynamics separate from state dynamics in machine learning / other domains?
I added some comments on outputs in https://github.com/SciML/ModelingToolkit.jl/issues/1111#issuecomment-946575620
Adding some thoughts to some points discussed in this issue:
if the output has its own dynamics then it's typically a state for control systems.
I agree, sensor dynamics etc. are probably best seen as part of the overall system dynamics.
Maybe it is more intuitive to specify the inputs and outputs when you actually want to compute the Jacobians. If you get an ODESystem from a Package e.g. JuliaSim you can not alter the variables of the predefined components, can you? I guess you could always make a top level model in which you specify the inputs and outputs.
Modelica has the concept of a sensor which you can connect to a physical, acausal signal. The sensor works as a one-way valve, outputting a causal signal. Sensors may have their own dynamics and add additional inputs (sensor noise). The same goes for inputs, where a signal source may be causally connected to an acausal signal, i.e., a current reference is connected to an electrical motor which produces a physical current in the motor windings.
I was talking with @YingboMa regarding #1209 and the behavior of any variables labelled as
output=true
. We discussed what the appropriate way to use them were, especially for computing the Jacobian with respect to a variable labelled asoutput
. The Jacobian can only be easily computed if anoutput
variable is explicit, i.e. can be an observed variable. This can create confusion in the workflow of MTK ifoutput
variables. Since we usually only have observed variables afterstructural_simplify
, this is problematic in the case of a partial model (e.g. #1211).What behavior is appropriate here? One idea is that we
structural_simplify
the partial model, but that is undesirable since it wouldn't produce a valid model. @ChrisRackauckas