Clarify need for start values in input clocks

[clagms]

Why do we force the FMU to provide a start value for a clock?

The following description is problematic:

it is required to provide a <<start>> value for describing the expected initial condition of master <<clock,`clocks`>> for that FMU. If an <<inputClock>> has `fmi3True` as an <<start>> value the master should activate the <<clock>> the first time it enters *Event Mode*. The master can nevertheless choose different <<start>> values if it is not possible to fulfill the conditions in a simulation setup.

Because:

1. For input periodic clocks, the offset, calculated as offset = interval * shiftCounter / resolution, can be zero, therefore the environment will (will it?) know when to execute them (right after initialization), without having the need for a start value for the clock.
2. For aperiodic input clocks, we cannot think of a usecase for an FMU declaring to the environment that he wants the environment to run one of its input clock right after initialization (plus this demand is not really a demand, as the master can choose to ignore it...)

@KarlWernersson , the working group on clocks need your input on this one.

[clagms]

• [ ] We also need to fix the smaller issue.

In case of <> <<inputClock,input clocks>> these values are the start interval values if they are not given by the simulation master.

This depends on the value of strict (as indicated in the subsequent paragraph).

[clagms]

Decision from web meeting 17-06-2020: drop the start value for ALL clocks.

[chrbertsch]

Ticket viewing Meeting:

Andreas: I belive we should be able to set values at the beginning and to have start values Klaus: but we decided otherwise above. Andreas: I see use cases for virtual ECUs, where it is important to state that a clock shall tick at the beginning. One could overwrite it at the beginning. TorstenB: In modelica during initialization, no clock ticks. The clock ticks first at eventMode Klaus: this seems to be a severly different interpretation. TorstenB: in Modelica during initialization no clock ticks. It first gets active in event mode. There might be requirements from other use cases. Andreas: We have similar issues with ECU SW ... I will have to look into this.

[andreas-junghanns]

This waits for clarification on clocks and events.

[andreas-junghanns]

Fixed in #1272. Changing clocks and Countdown clocks now allow ticks at the first Event Mode. For periodic clocks, this was always possible. This will handle the use case for initial tasks of vECUs.