Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added clarification on time increment #114

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Tc-Fast
Copy link
Contributor

@Tc-Fast Tc-Fast commented Jul 17, 2024

Closes #24

@@ -61,6 +61,10 @@ With FMI 2.0 Co-Simulation FMUs do not support 0-size time steps in any case.
With FMI 3.0, Co-Simulation FMUs can support event handling explicitly via the `hasEventMode` capability flag.
Importers can make use of this feature by passing `fmi3True` for the `eventModeUsed` argument of the `fmi3InstantiateCoSimulation` call.

=== Time increment

An accurate simulation is dependent on an accurate increment of time. The importer must therefore set the current simulation time in a non-error-cumulative manner. As the actual implementation of the time increment is importer specific and unknown to the imported FMU, the FMU itself should not make any assumptions about the precision of the next time steps.
Copy link
Collaborator

@pmai pmai Sep 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
An accurate simulation is dependent on an accurate increment of time. The importer must therefore set the current simulation time in a non-error-cumulative manner. As the actual implementation of the time increment is importer specific and unknown to the imported FMU, the FMU itself should not make any assumptions about the precision of the next time steps.
An accurate simulation is dependent on an accurate increment of time.
The importer must therefore set the current simulation time in a non-error-cumulative manner.
As the actual implementation of the time increment is importer specific and unknown to the imported FMU, the FMU itself should not make any assumptions about the precision of the next time steps.
This can mean, for example, that even in a fixed-step simulation the individual `communicationStepSize` values will differ by very small amounts.

Split into one sentence per line and added an explicit example of the last point which is maybe more on the nose for the target audience. Further discussion to be had in the next design meeting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add hint to use multiplication and not addition for time computation
2 participants