Clarification needed for independent variable

[modelica-trac-importer]

Reported by torstenblochwitz on 19 Mar 2014 15:56 UTC On page 46 the causality Attribute "independent" is defined.

Is it optional to define time as independent variable or mandatory? Does at least one variable needs to be defined with causality=independent?

---

Migrated-From: https://trac.fmi-standard.org/ticket/189

[modelica-trac-importer]

Comment by aviel on 19 Mar 2014 17:47 UTC By the way, what is the meaning of the "independent" causality variables (such as time) in the co-simulation context, since by construction time is enforced by the co-simulation stepping scheme?

[modelica-trac-importer]

Comment by otter on 31 Mar 2014 15:15 UTC Added clarification:

Exactly one ScalarVariable of an FMU must be defined as "independent". This variable must be defined as "Real". Attribute "start" must not be defined. It is not allowed to call function fmiSetReal on an "independent" variable. Instead, its value is set by fmiSetTime for ModelExchange and by arguments currentCommunicationPoint and communicationStepSize of fmiDoStep for CoSimulation. However, the actual value can always be inquired by fmiGetReal. [_It is recommended to use and

for the "independent" variable. If unit is not “s”, some tools might not support the connection with other FMUs._]

[modelica-trac-importer]

Comment by torstenblochwitz on 9 Apr 2014 08:00 UTC Decision at FMI Design Meeting 2014/04/08:

Keep independent variable as mandatory.

[modelica-trac-importer]

Comment by otter on 16 Apr 2014 16:27 UTC Here is an explanation for the decision to keep the "independent variable" in FMI 2.0:

• The "independent variable" definition in FMI allows to define a name and a unit for the independent variable. Assume for example that for efficiency reasons (as actually done) a tool provides the option to only expose a few variables to the outside of an FMU, and otherwise stores results of not exposed variables in a result file during simulation. Assume that a script is reading this result file to display signals. Then the script needs to know how to extract the values for the independent variable. This is only possible in a robust way, if a name for the independent variable is defined. Standardizing a name formally seems difficult, because tools have already their conventions how to name it (like "Time", "time", "t"). Storing the name of the independent variable in the FMU, solves the problem.

• In some applications, the partial derivative of the continuous-time equations with respect to (explicit) time is needed. The current solution allows this by calling fmi2GetDirectionalDerivative and provide a value reference for the independent variable. If the independent variable would not be stored in the xml-file, either such a partial derivative cannot be computed, or an additional argument has to be added to fmi2GetDirectionalDerivative that expresses this feature.

• There are technical applications where differential equations are solved and the independent variable is not time. E.g, for engine simulation it is common to use the engine angle as independent variable and not time (the differential equation is reformulated in the engine angle).

[modelica-trac-importer]

Comment by otter on 24 Apr 2014 10:16 UTC Reopened, in order to discuss this ticket at the web meeting today.

Here is an additional try to argue why an "independent" variable definition in the FMU is needed:

Assume that the following Modelica model is exported as FMU (either ModelExchange or CoSimulation):

der(x) = -x^3 + sin(w*time)

and imported in another environment. With function fmi2DirectionalDerivative it is possible to compute optionally directional derivatives (for ModelExchange at any time instant, for CoSimulation at communication points). These directional derivatives can be used by the integrator, or, say, to compute a linearized model to apply linear analysis methods. In both cases the FMU assumes that a system is mathematically described as:

der(x) = f(x, t)

Integrators and/or analysis methods based on Taylor series expansions require partial derivatives also with respect to time. For example the Taylor series for x is:

  x(t0+dt) = x0 + x'*dt + x''*dt^2/2 + ...
with
  x'  = der(x)
  x'' = der(x',x)*x' + der(x',t)
# der(f,x)*der(x) + der(f,t)

Therefore, in order that second or higher order terms can be computed, the partial derivative of f with respect to t is needed. If the independent variable is explicitely defined in the FMU, it is possible to compute this with fmi2DirectionalDerivative.

Some integration methods are only suited for autonomous systems (der(x) = f(x)), such as Rosenbruck integrators. In this case the environment needs a way to determine whether the FMU depends explicitly on t or not. This information can be deduced from the ModelStructure (but only, if the independent variable is defined in the FMU). This information can be used to internally reformulate the FMU in a form that can be handled by the integrator (by introducing an additional state, x_add = t, der(x_add)=1, and replacing conceptually the explicit occurrences of t by x_add)

To summarize, without explicitely defining the independent variable in the FMU, the characterization of the FMU is incomplete and some analysis features cannot be applied.

It would be possible to introduce an implicit rule:

If an independent variable is not defined in the XML-file, then this means:

• the independent variable has name "time"
• the unit of the independent variable is "s"
• the FMU does not explicitely depend on time

It seems however, that such an implicit rule makes the definition unnecessarily complex.

[modelica-trac-importer]

Comment by hansolsson on 24 Apr 2014 11:53 UTC The question is how far we want to support Rosenbrock methods, and other unusual variants - without making the standard too complex to support for tools. Note that Rosenbrock-methods can also be applied to models where the right-hand-side depend on time - it is just messier (technically they can even be applied with numeric derivatives.)

If we consider usual cases, then A,B,C,D matrices for derivatives is something we can expect - and also see in other tools. However, analytic df/dt as used by Rosenbrock methods is something that is usually lacking, similarly as dependency information with regards to time for all variables.

Thus I would propose that if no time is present then it is assumed to be called time (with unit "s") - and all variables in the FMU explicitly depend on time (i.e. exactly opposite the previous proposal). In this case the directional derivatives with respect to time cannot be computed - even if the FMU provides directional derivatives.

If the independent variable is declared then dependencies must be listed, and directional derivatives with respect to time can be computed (if the FMU provides directional derivatives at all).

This allows a traditional exporting tool to generate FMUs and provide some derivatives - and some dependencies, and reduces the risk of independent variable being declared - but not handled consistently. Yes, such an FMU will be "incomplete" and some analysis features cannot be applied.

[modelica-trac-importer]

Comment by otter on 24 Apr 2014 13:02 UTC Replying to [comment:6 hansolsson]:

The question is how far we want to support Rosenbrock methods, and other unusual variants - without making the standard too complex to support for tools. Note that Rosenbrock-methods can also be applied to models where the right-hand-side depend on time - it is just messier (technically they can even be applied with numeric derivatives.)

If we consider usual cases, then A,B,C,D matrices for derivatives is something we can expect - and also see in other tools. However, analytic df/dt as used by Rosenbrock methods is something that is usually lacking, similarly as dependency information with regards to time for all variables.

Thus I would propose that if no time is present then it is assumed to be called time (with unit "s") - and all variables in the FMU explicitly depend on time (i.e. exactly opposite the previous proposal). In this case the directional derivatives with respect to time cannot be computed - even if the FMU provides directional derivatives.

If the independent variable is declared then dependencies must be listed, and directional derivatives with respect to time can be computed (if the FMU provides directional derivatives at all).

This allows a traditional exporting tool to generate FMUs and provide some derivatives - and some dependencies, and reduces the risk of independent variable being declared - but not handled consistently. Yes, such an FMU will be "incomplete" and some analysis features cannot be applied.

Fixed as suggested.