Transfer variables after initialisation #766
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fixed_step_algorithm::initialize()
ends by callingsimulator::start_simulation()
, which, for an FMI 2.0 FMU ends up callingfmi2ExitInitializationMode()
. This function is not prohibited from modifying variable values, which means that we must assume that it does. Previously we did not, and this has led to issue #609, which to me looks like a pretty severe correctness issue. Here, I've addedget_variables()
andset_variables()
calls at additional points in the call sequence of aslave_simulator()
where variable values may have changed, and I've added a variable transfer at the end offixed_step_algorithm::initialize()
.I've run the quarter-truck case to verify that these changes actually do fix #609:
The PR also fixes #762 (in the same way that PR #765 does – they have a common change in
slave_simulator.cpp
).