support connections between (causal) variables connect(var1, var2)

[baggepinnen]

In modelica and JSML one can connect two variables that are marked as output and input. In MTK, we can currently only connect systems that are @connector, and we thus have the RealInput, RealOutput in MTKstdlib. This is awkward, and makes the translation from JSML to MTK difficult.

This request is to allow connect between two variables

@variables u(t) [input = true] y(t) [output=true]

connect(y, u)
connect(y, :analysis_point_name, u)

and these connect statement should normally expand to u ~ y, unless an analysis is requested.

[AayushSabharwal]

It seems reasonable. I'm not sure how much the connection code will like this, but it's worth trying.

[baggepinnen]

It can be made to like it 😊

[mtiller-jh]

@baggepinnen are you then implying that the following JSML code:

connect(y, u)
u1: analysis_point(y, u)

should generate code that looks like this:

connect(y, :u1, u)

...after this issue is resolved? A key point here is that connect statements (at least in JSML) are unordered. I don't know about MTK, but if I understand you correctly, these are semantically different in MTK (or at least should be):

connect(u, :u1, y)
connect(y, :u1, u)

So during JSML code generation, I would follow the ordering in the analysis_point statement when generating the MTK code, right?

[baggepinnen]

They are semantically different in MTK right now, but we would most of the time have the required information to enforce that an output is connected to one or several inputs, so we could also decide that the order is unimportant, I.e., the two connect statements are semantically identical and error if the user passes anything that isn't an IO connection.

[ggkountouras]

How will this handle multi-connections?

connect(x, :u1, y, z)

[baggepinnen]

How will this handle multi-connections?

It is already handled by the analysis-point code, as long as at most one connector is an output and the other ones are inputs. The semantics then are

connect(output, input1, input2, input3)

expands to

output ~ input1
output ~ input2
output ~ input3