-
Notifications
You must be signed in to change notification settings - Fork 4
Description
This is only a minor clarification, but since there has been some confusion about the purpose of the NRT-states I thinks its good the explain things clearly.
I propose the following clarification on pages 22/23(changes in bold):
If no state COMPUTED would exist, he would immediately send its outputs to slave B
and changes to state RUNNING.
Slave B might receive this data before having received the STC_do_step from the
master, due to network delay, latency, etc.
Thus, he would calculate with input data not consistent to current simulation time instance.
Explicitly triggering the sending of outputs using the STC_send_outputs PDU prevents this.
This is not related to the state sending_d itself since transitioning to running from computed on command would achieve the same result. The purpose of state computed is to wait for a signal to send data.
Further explanation of state sending_d could read as:
On the other hand, if a sequential order of execution is desired in which slave B should calculate with most recent data of slave A,
the state SENDING_D can be used to ensure deterministic execution of the simulation.
If a reliable transport medium is used, asynchronous sending of data in state SENDING_D
guarantees that a slave A will transition to state RUNNING after the sent data has been received.
The master can then send STC_do_step to the receiving slave B after the master has received the notification that slave A is in state running.
This prevents a situation in which it is undetermined whether slave B calculates with already received latest inputs or not yet having received them due to network delay.
See the discussion in https://github.com/modelica/dcp-design/issues/86#issuecomment-436726546
The way I see it, the decision was reached to rely on the underling transport medium in combination with these states for determinism.