inflow/outflow of terminals

[friedrichatgc]

inflow and outflow is used for all connected variables following Kirchhoff’s current law. The value is defined as positive if the flow-media is flowing in or out of the FMU, respectively. However, what is about quantities following Kirchhoff's current law but not having a flow direction like a mechanical force? The sign of such flow variables are completely undefined by the standard. Sure, terminal standards on top of FMI may defined this. But I think the standard should either probably define the sign for ALL flow variables or for NONE (leaving this open for terminal standards defined on top of FMI).

Hence, I propose to combine the inflow/outflow variableKind into a single "flow" variableKind which just states that the variable is following Kirchhoff's current law but leafs the sign definition open. Alternatively we may define a proper sign definition for ALL flow variables, but this may be complicated and/or highly domain specific. Another alternative would be to keep the existing inflow/outflow since it is especially useful for the stream variables (which always have a flow direction) and add a "flow" variableKind being the same as inflow/outflow but without a definition of the sign.

[CSchulzeTLK]

For several domains I see a clearly defined direction. E.g.: Heat flow, mass flow and electrical current. However, from a users persective often the local balance equations are not relevant, but rather the flow over several components. So many tools only show and provide one flow direction sign, i.e. an inflow variable at the "inlet" and an outflow variable at the "outlet" - if it is clear what inlet and outlet are.

For translational and rotational I'm not an expert, but others seem to see a physical interpretation: https://mbe.modelica.university/components/connectors/simple_domains/

"For example, in the case of translational motion the flow variable, f, is a force and force is the time derivative of (linear) momentum and momentum is a conserved quantity." "As with all previous examples, the flow variable is the time derivative of a conserved quantity. In this case, that conserved quantity is angular momentum."

Do these descriptions clarify the issue?

Anyhow, the idea is that other standards will define domain specific terminals. This includes in my understanding such conventions.

[antvl]

Originally, only the "flow" attribute was planned, but later it seemed that we need to define the sign convention for the flow variables to avoid ambiguities and free the end user from having to manage this. This is why inflow is distinguished from outflow. At the time an FMU is created the exporting tool necessarily knows which sign convention is to be applied to the model, so I don't understand how we could have a flow variable with undefined sign convention? Perhaps this is annoying for the importing tool which uses the other sign convention, but this is a general principle of the FMI standard that the exporting tool always enforces its specific choices for the FMU it creates and the importing tool has to deal with it.

[CSchulzeTLK]

Working Group Meeting on 03.04.2020 (@antvl , @friedrichatgc , @CSchulzeTLK ):

We decided to add the non-normative text: "inflow" and "outflow" are used as a sign convention for one-dimensional flow variables. If the flow direction needs definition beyond of this (e.g. direction in space) this is not fully defined. E.g. for 3D mechanical systems, the reference frame needs to be defined and propagated, but this is not the scope of this specification. This has been already been defined implicitly, because 3D mechanics does not use the Kirchhoff's current law, but the quite analogue D'Alambert principle.

[chrbertsch]

Design Meeting:

Christian S: Domain specific tools often show variables with the same sign (opposed to Modelica). This was the reason why we introduced configuration possibility for the sign convention. But for 3d-mechanical this does not really make sense. We already stated that this is is used for Kirchhoff Current law ....

Klaus: For 3d mechanical systems one would need a common coordinate system

Markus: We can define flow variables. the sum must be zero. For 1d the sign is defined by inflow and outflow. But for 3d mechanics: it is not enough to define the inflow or outflow, but one need the direction. We propose to clarify that this can be only used for 1d variables. One could defined standards on top FMI 3.0

Klaus: One could also agree on on a flow per coordinate variable

Markus: one needs a world reference frame.

Pierre: It is up to the FMU implementers whether a higher-dimensional array makes sense as an inflow or outflow. This does not work for higher dimensions.

Markus: Why?

Pierre: Works only for "nearly scalar" stuff. I would not use the word "dimension" or "dimensionality" as used by the FMI standard.

@friedrichatgc and @CSchulzeTLK will create a PR