Only force unbound causal inputs to be states

[ValentinKaisermayer]

ModelingToolkit.jl/src/systems/connectors.jl

Line 51 in 6b92d37

@warn "$(nameof(sys)) contains $n_flow variables, yet $n_regular regular " *

Considering that input=true seems to force a variable to be a state, which is an undocumented behaviour and seems to change the behaviour of the model, I would suggest to change this to @debug for now.

[YingboMa]

input=true forces a variable to be a state is intended. Otherwise users won't be able to change it in a callback.

[ValentinKaisermayer]

Ok, but why the warning?
For instance in MTKSL the PID Block consists of about 10 blocks, each with inputs. The PID block itself has inputs. The state vector would be 10+ states, with a single PID block in the model. I do not think that this is what the user expects. On the other hand if the meta data is not assigned the warning is thrown, which also is not what a user of MTKSL will expect.

I can see the usefulness of the variable being in the state vector but it should be limited to very few cases and not be advertised as if it does not hurt.

[ValentinKaisermayer]

I think checking if physical connectors (with >=2 variables) to have flow and potential (voltage/current, temp./heat flow,...) is fine.
It might be a good idea to add a type Potential for this.
Modelica has strict rules for this.
https://specification.modelica.org/master/connectors-and-connections.html
https://specification.modelica.org/master/stream-connectors.html

A side note: the signal connectors of Modelica RealInput and RealOutput have no variable at all and simply can be used in place of a connector and of a variable. In MTKSL using the e.g. RealInput requires you to use input.u, which is more verbose than it needs to be.

[ValentinKaisermayer]

Can we add CausalInput and CausalOutput as type, like Flow and do the check of the connector based on the types? I think this is more consistent than having it as metadata. Also an input should not end up as state per se. If this is needed for changing an (external) input in a callback function, it is an implementation detail and has nothing to do with the modelling.

The following system has one state (from the integrator), however, with MTK and the inputs of the blocks annotated with input=true (otherwise the warning from above) it has five.

using ModelingToolkitStandardLibrary.Blocks
using ModelingToolkit, OrdinaryDiffEq

@parameters t

@named c = Constant(; k=2)
@named gain = Gain(1;)
@named int = Integrator(; k=1)
@named fb = Feedback(;)
@named model = ODESystem(
    [
        connect(c.output, fb.input1), 
        connect(fb.input2, int.output), 
        connect(fb.output, gain.input),
        connect(gain.output, int.input),
    ], 
    t, 
    systems=[int, gain, c, fb]
)
sys = structural_simplify(model)

julia> sys
Model model with 5 equations
States (5):
  int₊x(t) [defaults to 0.0]
  int₊input₊u(t) [defaults to 0.0]
  gain₊input₊u(t) [defaults to 0.0]
⋮
Parameters (3):
  int₊k [defaults to 1]
  gain₊k [defaults to 1]
  c₊k [defaults to 2]
Incidence matrix:5×6 SparseArrays.SparseMatrixCSC{Num, Int64} with 10 stored entries:
 ×  ⋅  ×  ⋅  ⋅  ⋅
 ⋅  ⋅  ⋅  ⋅  ⋅  ×
 ⋅  ×  ⋅  ⋅  ×  ⋅
 ⋅  ⋅  ⋅  ×  ×  ×
 ⋅  ⋅  ×  ×  ⋅  ⋅

[ValentinKaisermayer]

An even more grotesk example:

using ModelingToolkitStandardLibrary.Blocks
using ModelingToolkit, OrdinaryDiffEq

@parameters t

"""Second order demo plant"""
function Plant(;name, x_start=zeros(2))
    @named input = RealInput()
    @named output = RealOutput()
    D = Differential(t)
    sts = @variables x1(t)=x_start[1] x2(t)=x_start[2]
    eqs= [
        D(x1) ~ x2
        D(x2) ~ -x1 - 0.5 * x2 + input.u
        output.u ~ 0.9 * x1 + x2
    ]
    compose(ODESystem(eqs, t, sts, []; name), [input, output])
end

re_val = 1
@named ref = Constant(; k=re_val)
@named pid_controller = LimPID(k=3, Ti=0.5, Td=100, u_max=1.5, u_min=-1.5, Ni=0.1/0.5)
@named plant = Plant()
@named model = ODESystem(
    [
        connect(ref.output, pid_controller.reference), 
        connect(plant.output, pid_controller.measurement),
        connect(pid_controller.ctr_output, plant.input), 
    ], 
    t, 
    systems=[pid_controller, plant, ref]
)
sys = structural_simplify(model)

julia> states(sys)
24-element Vector{Term{Real, Base.ImmutableDict{DataType, Any}}}:
 pid_controller₊int₊x(t)
 pid_controller₊der₊x(t)
 plant₊x1(t)
 plant₊x2(t)
 pid_controller₊addP₊input1₊u(t)
 pid_controller₊addP₊input2₊u(t)
 pid_controller₊gainPID₊input₊u(t)
 pid_controller₊addPID₊input1₊u(t)
 pid_controller₊addPID₊input2₊u(t)
 pid_controller₊addPID₊input3₊u(t)
 pid_controller₊limiter₊input₊u(t)
 pid_controller₊addSat₊input1₊u(t)
 pid_controller₊addSat₊input2₊u(t)
 pid_controller₊gainTrack₊input₊u(t)
 pid_controller₊addI₊input1₊u(t)
 pid_controller₊addI₊input2₊u(t)
 pid_controller₊addI₊input3₊u(t)
 pid_controller₊int₊input₊u(t)
 pid_controller₊addD₊input1₊u(t)
 pid_controller₊addD₊input2₊u(t)
 pid_controller₊der₊input₊u(t)
 plant₊input₊u(t)
 pid_controller₊reference₊u(t)
 pid_controller₊measurement₊u(t)

[baggepinnen]

The detection of is_bound does not work for connectors, or rather, it works as intended but the notion of being bound does not fit with the use of the connector since the [input=true] variable will be connected to a variable in an outer namespace as soon as you have attached the connector to the host component

[ValentinKaisermayer]

Can we simply let the user do this and use types CausalInput and CausalOutput in a connector? This also would allow for more checks, see #1626. If the user wants to have access to a variable it can be forced into the state vector via [irreducible=true] (this is only ever needed for callback functions I think).

I'm not sure what the intended use-case for [input=true] is and why there is a need for [irreducible=true] as well.
Maybe you can explain it to me.

One use-case I see is system linearization.
If I think of how Simulink does this, you would take your model and annotate it with inputs and outputs. However, in MTK this is not needed. One can simply provide the reference to a variable linearize(sys, [in1, in2], [out1, out2]). I do not see why this should be part of the modelling.

[baggepinnen]

There are a few use cases I have in mind, the most important is that one should be able to call structural_simplify on systems that have inputs that are not connected as well as to generate code for systems that take the input as an argument, e.g.,

ẋ = dynamics(x, u, p, t)

One approach would be as you mention, to force the user to connect a CausalInput to a signal to explicitly indicate that this is an input. I'm not sure how the struct Flow type differs from metadata, but it's quite possible there are better ways of implementing it than the current approach.

[ValentinKaisermayer]

the most important is that one should be able to call structural_simplify on systems that have inputs that are not connected

What do you mean? What outcome do you expect from that?