Control over independent variables

[christian-wolf-eks]

Hello,

the independent variable (time) has a special meaning. This becomes clear when reading the standard.

Problem formulation

Assume a CS FMU defines an explicit time variable in the manifest. So, there is something like

<ModelVariables>
  <Float64 name="time" valueReference="1" description="Simulation time" causality="independent" />
</ModelVariables>

The importer is not allowed to set the time (according to 2.4.7 Table 17 row causality) using fmi3SetFloat64(...). This means that the FMU will have to set an internal time variable to the currentCommunicationPoint value upon entry of fmi3DoStep and add communicationStepSize during the execution (ideally) (see 4.2.1 parameter description on fmi3DoStep).

If there is a fixed step solver under the hood that cannot exactly reach the next planned communication point, lastSuccessfulTime should be set to the end of the last internal integrator interval. The internal time will be just the same value.

The examples in 4.3 do not help much either to understand the problem further. In 4.3.1 the time is controlled by the importer and blindly applied (although there is no time variable explicitly used). In 4.3.2 the time is synchronized by using lastSuccessfulTime back to the importer. Again, this does not incolce an explicit time variable.

Context in standard

For ME the simulation environment controls the time, which is written in 2.2.6:

In Model Exchange, time is under the sole control of the importer and its integration algorithm. The model itself receives the current time to be used in its computation with fmi3SetTime. Time is not necessarily always advancing as solvers might need to jump back and forth in time, for example, to localize events using event indicators.

For CS however, the text is not obvious to me, to be honest. The standard continues with:

In Co-Simulation, time advances in (possibly variable) steps negotiated between the co-simulation algorithm of the importer and the FMU. The importer calls fmi3DoStep with the currentCommunicationPoint and a target communicationStepSize (required to be larger than 0.0).

This just states that the time in CS needs to be in sync. OK so far. This does not define which instance (importer or instanciated FMU) should keep track of time (or both).

The reminder of this paragraph is about early returning of a communication step. So, it does not give any clear statement here:

During this fmi3DoStep, both importer and FMU might encounter events (or other situations) that require reduction of the communicationStepSize (potentially even down to 0.0). The FMU may use the return argument earlyReturn of the fmi3DoStep function to tell the importer that the FMU returned earlier than requested. The importer may use the return argument earlyReturnRequested of the callback fmi3IntermediateUpdateCallback to signal the FMU to return early from the current fmi3DoStep. The output argument lastSuccessfulTime of fmi3DoStep allows the FMU to signal the importer its current internal time.

Questions / comments

1. Are my conclusions about how time is stored and synced correct?
2. I find this rather counter-intuitive (to read and grasp in a straight way) in the standard as you need to combine various information to get there. Did I miss an essential part (author's guilde,...)?
3. What is the point of the time (independent) variable in case of CS at all if the FMU has its internal time value and syncs with the importer by means of arguments to the fmi3DoStep call?

Maybe further questions come up in time but let's get the rough questions be addressed first.