fixed_step_algorithm::initialize() ends by calling simulator::start_simulation(), which, for an FMI 2.0 FMU ends up calling fmi2ExitInitializationMode(). 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 added get_variables() and set_variables() calls at additional points in the call sequence of a slave_simulator() where variable values may have changed, and I've added a variable transfer at the end of fixed_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).
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).