Behavior of `output`

[dannys4]

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 as output. The Jacobian can only be easily computed if an output variable is explicit, i.e. can be an observed variable. This can create confusion in the workflow of MTK if output variables. Since we usually only have observed variables after structural_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

[dannys4]

@cadojo @JTaets @jonniedie @baggepinnen @MuradTroll @ronisbr Pinging some people who had thoughts on control systems in prior issues

[cadojo]

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!

[dannys4]

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?

[ValentinKaisermayer]

Couldn't you test for this and throw an exception that the ODESystem can not be converted into an explicit form?

[ValentinKaisermayer]

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.

[dannys4]

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).

[ValentinKaisermayer]

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.

[MuradMathematics]

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).

[cadojo]

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?

[baggepinnen]

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.