Clarification of InitialUnknowns

[modelica-trac-importer]

Reported by awittkop on 5 Jul 2014 19:04 UTC The definition on pg. 57 states that 'InitialUnknwons' is an ordered list of all exposed Unknowns in initialization mode. I just want to be clear that this includes continuous values that have initial="approx", e.g. for an FMU that solves a DAE problem and internally uses projection.

In contrast, on pg. 75 it is described that the inputs to f[init]() are the InitialUnknowns. Should that read 'outputs'?

Note in the chart on pg. 102 it is stated that in initialization mode, only causality="output" values also present in the InitialUnknowns can be use in a Get. Why is this restriction necessary?

---

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

[modelica-trac-importer]

Modified by torstenblochwitz on 7 Jul 2014 07:19 UTC

[modelica-trac-importer]

Comment by otter on 7 Jul 2014 12:26 UTC Replying to [ticket:258 awittkop@…]:

The definition on pg. 57 states that 'InitialUnknwons' is an ordered list of all exposed Unknowns in initialization mode. I just want to be clear that this includes continuous values that have initial="approx", e.g. for an FMU that solves a DAE problem and internally uses projection.

Hm. As long as the "continuous values" are defined as "outputs" (with initial="approx") this is o.k. and part of the current definition that states "The list must include at least all outputs that do not have initial=exact". If you have internal variables (so variables with causality = "local"), such as projection variables or iteration variables of nonlinear algebraic loops, then these variables are internally solved during initialization and are not reported to the outside. So these are "initial unknowns", that are not exposed (this just means that the FMU is responsible to compute them; the environment is only responsible to compute the initial unknowns reported in InitialUnknowns).

In contrast, on pg. 75 it is described that the inputs to f[init]() are the InitialUnknowns. Should that read 'outputs'?

You are right, this is not clear (what is meant is, that the Known variables are defined in the comment of ). To make this clearer, I changed the sentence to: The input arguments to this function consist of the input variables (= variables with causality = "input"), of the independent variable (= variable with causality = "independent"; usually the default value "time") and of all variables that have a start value with (explicitely or implicitely) initial = "exact" in order to compute the continuous-time states and the output variables at the initial time t0.

Note in the chart on pg. 102 it is stated that in initialization mode, only causality="output" values also present in the InitialUnknowns can be use in a Get. Why is this restriction necessary?

Hm. In the table it is stated: fmiGetXXX in Initialization Mode is allowed for a variable defined in the xml-file under and for a variable with causality = "output"

So this means that all can be inquired with fmiGetXXX, as well as all outputs. The outputs with initial=approx or initial=calculated are part of . However, the outputs with initial=exact are not, but it is allowed to call fmiGetXXX on them.

[modelica-trac-importer]

Comment by kkowalska on 7 Jul 2014 14:58 UTC It is still not clear what should be considered an InitialUnknown. The definition on pg. 57-58 of the RC2 Draft 1 spec states that:

This list must include at least all outputs, and all continuous-time states that do not have initial=”exact” and without duplicates (e.g. if a state is also an output, it is included only once in the list).

This definition implies that non-output state variables with initial="approx" can also be in InitialUnknowns.

Also, regarding "the environment is only responsible to compute the initial unknowns reported in InitialUnknowns", we were under the impression that the FMU computes the InitialUnknows and the environment just queries the values using fmiGet*. How can the environment compute these unknowns when they're outputs of an FMU?

[modelica-trac-importer]

Comment by otter on 8 Jul 2014 08:44 UTC Replying to [comment:3 kkowalska@…]:

It is still not clear what should be considered an InitialUnknown. The definition on pg. 57-58 of the RC2 Draft 1 spec states that:

This list must include at least all outputs, and all continuous-time states that do not have initial=”exact” and without duplicates (e.g. if a state is also an output, it is included only once in the list).

This definition implies that non-output state variables with initial="approx" can also be in InitialUnknowns.

Sorry, you are right. All variables (also local ones) that are computed in the FMU (so initial="approx" or "calculated") can be in the InitialUnknowns list.

Also, regarding "the environment is only responsible to compute the initial unknowns reported in InitialUnknowns", we were under the impression that the FMU computes the InitialUnknows and the environment just queries the values using fmiGet*. How can the environment compute these unknowns when they're outputs of an FMU?

Sorry, you are completely right: The environment provides the knowns (inputs, variables with initial="exact") and the FMU computes all variables listed in InitialUnknowns.

I have clarified this in the specification and in the schema file. Especially, the definition of InitialUnknowns is now: Ordered list of all exposed Unknowns in Initialization Mode, that is all variables that are computed in Initialization Mode. This list must include at least all outputs, and all continuous-time states that do not have initial=”exact” and without duplicates (e.g. if a state is also an output, it is included only once in the list). This list may (optionally) include additionally variables with initial=”approx” or initial=”calculated” after removing all duplicates.

[modelica-trac-importer]

Comment by otter on 8 Jul 2014 19:32 UTC I had a phone meeting with Chad and Kaska (Maplesoft) to discuss this ticket. Here is the conclusion as I understand it:

The primary goal of the Initialization Mode is to compute

1. all output variables (since they are potentially used in FMU connections during initialization and it must therefore be possible to compute them).

2. all variables that are treated as "known" input arguments in the other Modes (for ModelExchange, these are at least all continuous-time states with initial=approx or calculated and variables with variability=calculatedParameter; for Co-Simulation these are only variables with variability=calculatedParameter, because continuous-time states are not exposed by default).

Additionally, an FMU (both ModelExchange and Co-Simulation) may solve algebraic loops during initialization and if the FMU is connected with other FMUs, also algebraic loops over the FMU connection may appear. In order that the environment can monitor issues during initialization in such cases, it is important that the values of iteration variables can be inquired (= variables with init=approx.). In order to simplify the definition, a tool may also support inquirey of variables with init=calculated as well.

Based on the above observations, it is proposed to clarify/adapt the rules for InitialUnknowns:

InitialUnknowns are an ordered list of all exposed Unknowns in Initialization Mode, that is all variables that are computed in Initialization Mode and can be inquired with fmi2GetXXX. This list must include at least all variables with variability = "output" or "calculatedParameter". For ModelExchange, this list must additionally include at least all continuous-time states with initial="approx" or "calculated". The resulting list is not allowed to have duplicates (e.g. if a state is also an output, it is included only once in the list). This list may optionally include variables with initial=”approx” or initial=”calculated” after removing all duplicates.

[modelica-trac-importer]

Comment by otter on 9 Jul 2014 08:06 UTC I had a phone meeting with Karl and Sven Erik from DS, and the discussion revealed some minor corrections to the previous proposal:

One has clearly to distinguish what are Knowns and what are Unknowns. Therefore, in the InitialUnknowns list only the variables that are computed can be included (so initial=approx and calculated, but not exact; for inital=exact the variable is explicitly set to its start value and therefore it is a Known variable in this phase. This means, only outputs with initial=approx and calculated but not exact are in the InitialUnknowns list. Furthermore, it should be allowed to inquire also a Known variable with fmi2GetXXX. Finally, state derivatives should be mentioned (due to the often occurring initialization condition der(x) = 0, which means der(x) has initial=calculated in this case). Therefore, the slightly improved proposal is:

InitialUnknowns are an ordered list of all exposed Unknowns in Initialization Mode, that is all variables that are computed and exposed in Initialization Mode. This list must include at least all variables that are used as Knowns in the other modes, so variables with (a) variability = "output" and (initial="approx" or "calculated"), and (b) variability = "calculatedParameter", and (c) for ModelExchange, at least all continuous-time states with initial="approx" or "calculated". The resulting list is not allowed to have duplicates (e.g. if a state is also an output, it is included only once in the list). This list may optionally include variables with initial=”approx” after removing all duplicates (this is recommended in order that the environment can monitor FMU internal iteration variables of algebraic loops) and variables with initial="calculated" (such as state derivatives of steady state equations, so computed as der(x)=0). All variables in the InitialUnknown list, as well as all Knowns in InitializationMode can be inquired with fmi2GetXXX.

[modelica-trac-importer]

Comment by otter on 9 Jul 2014 10:33 UTC In the specification included the following text at the place where InitialUnknowns is defined (and a shortened version of this text as comment in the fmi2ModelDescription.xsd file):

Ordered list of all exposed Unknowns in Initialization Mode. This list must include at least all variables that are used as Knowns in the other modes, so variables with

1. variability = "output" and (initial="approx" or "calculated"),

2. variability = "calculatedParameter", and

3. for ModelExchange, continuous-time states with initial = ("approx" or "calculated")

   This list may optionally include:

4. variables with initial = "approx" [(this is recommended in order that the environment can monitor FMU internal iteration variables of algebraic loops)] and

5. variables with initial = "calculated" [(such as state derivatives in steady state case computed as dx/dt=0)].

   The resulting list is not allowed to have duplicates (e.g. if a state is also an output, it is included only once in the list).

[modelica-trac-importer]

Comment by otter on 16 Jul 2014 13:08 UTC Karl from DS pointed out that the new rules are confusing. The reason is that for all a dependency list can be given (so the incidence matrix of the Unknowns with respect to the Knowns). The question is how to utilize this information? During Continuous-Time Mode (for ModelExchange), the incidence can be only defined for outputs and state derivatives. It is then confusing that for initialization, the incidence can be given also for local variables, whereas this information is not present in the other modes. Therefore, this feels fichy.

I tried to analyse this in more detail:

The central question is which variables can be used in other models? On page 46 it is defined:

• "parameter": Independent parameter (a data value that is constant during the simulation and is provided by the environment and cannot be used in connections).
• "calculatedParameter": A data value that is constant during the simulation and is computed during initialization or when tunable parameters change
• "input": The variable value can be provided from another model or slave.
• "output": The variable value can be used by another model or slave.
• "local": Local variable that is calculated from other variables or is a continuous-time state. It is not allowed to use the variable value in another model or slave.

This definition is not completely clear, because it is not defined whether "parameter" and "calculatedParameter" can be used in another model. For a Modelica model, public parameters and calculated parameters can be accessed by other models and therefore it seems to make sense to keep this property when generating an FMU. Therefore, a clarification should be added that "parameter" and "calculatedParameter" can be accessed by other models (if a Modelica model has protected parameters or calculatedParameters, mapping to an FMU then either is performed by not exposing these variables, or if they shall be exposed, to map them to local variables with variability = fixed or tunable).

The above definitions (with the clarification for parameters and calculatedParameters) are fine for Non-Initialization Mode. If they would be directly utilized for InitializationMode too, then the current definition of the InitialUnknowns does not make sense and should be changed to:

InitialUnkowns: This list must include all variables with variability = "output" and (initial="approx" or "calculated"), as well as variability = "calculatedParameter".

The reason is that the only Unkowns in InitializationMode that can be used in other models are outputs and calculatedParameters, and therefore nonlinear equations over FMUs can be only formulated over these variables. As a consequence, dependency information is only needed for these variables in InitializationMode.

However, this definition seems to be too restrictive for applications (e.g. most of the test cases under FMITest.Initialization - the Modelica library to test connected FMUs - would be no longer valid). Take for example the often occuring case:

• An FMU defines state initialization: so x0,t0 given and der(x) = f(x,u), y = g(x,u)
• The environment would like to initialize in steady-state by defining x0 as iteration variable and adding the additional equation "der(x)=0" in the environment (so x0 is modified in the environment until the der(x) computed by the FMU is close to zero).

Such an application requires that the state derivatives der(x) can be used in another model during Initialization Mode (and for symmetry also allow access of the continuous states x).

The big question is whether all other local variables are also allowed to be accessed in other models (e.g. to vary x0, such that a local variable gets a particular value). Intuitively, these might give confusion, because local variables can be accessed in InitializationMode but not in the other modes. If someone would like to provide such a feature, the local variable should be provided as an output (the goal to mark variables as outputs and as locals was, to make a separation of the variables that can be accessed in other models (= outputs) and variables that are only used for plotting, but cannot be utilized in other models).

From the discussion above, my conclusion is one of the following two variants:

Variant 1: InitialUnkowns: This list must include all variables with (1) variability = "output" and (initial="approx" or "calculated"), (2) variability = "calculatedParameter". Optionally this list may include (3) all continouous-time states and all state derivatives with initial="approx" or "calculated".

Variant 2: InitialUnkowns: This list must include all variables with (1) variability = "output" and (initial="approx" or "calculated"), (2) variability = "calculatedParameter" (3) all continouous-time states and all state derivatives with initial="approx" or "calculated".

I have no strong opinion whether Variant 1 or 2 should be used (Variant 2 is better for the end-user, because he/she has more possibilities to influence the initialization of an FMU).

[modelica-trac-importer]

Comment by karl.wernersson on 16 Jul 2014 14:51 UTC I support this definition it is clear to me and it is close to how I interpreted the original definition.

For which variant to use I nether have a strong opinion. As you stated Variant 2 is better for end user but if exporting tool vendors have problems with this it is better to make it optional then have sloppy implementation.

/Karl Wernersson (DS Lund)

[modelica-trac-importer]

Comment by awittkop on 16 Jul 2014 15:41 UTC In the above I think you meant 'causality' instead of 'variability'.

We vote for option #2:

Variant 2: InitialUnknowns: This list must include all variables with (1) causality = "output" and (initial="approx" or "calculated"), (2) causality = "calculatedParameter" (3) all continouous-time states and all state derivatives with initial="approx" or "calculated".

We may want this issue repoened when DAE support is added into FMI.

[modelica-trac-importer]

Comment by otter on 16 Jul 2014 17:56 UTC I have now fixed this in this specification, the state machines, the function call table and in the examples in https://github.com/modelica/fmi-design/commit/512cfb909ad1a17f3c541058151718f2b91128e2 and https://github.com/modelica/fmi-design/commit/d886615b8ea55dfabfb0c58e05ce9b0a9b17e8ca.

I used variant (2) because otherwise this becomes a mess: Assume a tool stores some of the states with initial="approx" or "calculated" in InitialUnknowns, but not all. This means a user really has to inspect InitialUnknowns to figure out what he can inquire. Furthermore, fmi2GetContinuousStates is then questionable, if only part of the states is provided as InitialUnknowns. I reformulated this in the state machine and in the function call table such that fmi2GetXXX is allowed on outputs, continuous-time states and state derivatives (the latter two only, if the element is present, so the states are exposed).

One could now argue that the InitialUnknowns list could be completely removed, if no dependencies are given, because the list can then be constructed from available information. In order to not change too much now, I did not introduce this change.

[modelica-trac-importer]

Modified by otter on 18 Jul 2014 15:51 UTC