Pre-simulation iterations are handled incorrectly for FMI v1.0 FMUs

[kyllingstad]

At the start of a co-simulation, FMI allows you to "warm up" the system by iterating to some desired state before time starts to run. We make use of this in fixed_step_algorithm::initialize(), where we perform N iterations, where N is the number of simulators in the system.

However, this is handled differently in FMI 1.0 and 2.0:

• In 1.0, the "initialisation phase" is simply a period at the start of the simulation where you repeatedly call the step function with zero step size; that is:
  1. set_vars()
  2. do_step(0)
  3. get_vars()
  4. goto i
• In 2.0, the initialisation phase is clearly delineated from the simulation phase by a call to fmi2ExitInitializationMode(). Before that, you simply do set_vars(), get_vars(), without an intervening do_step().

I don't think we're handling the 1.0 case correctly in CSE at the moment. The slave interface is supposed to behave like FMI 2.0, and we need to adapt the FMI 1.0 back end to that. That means that the intervening do_step(0.0) must be inserted behind the scenes in fmi::v1::slave_instance by detecting whether a get_xxx_variables() is called immediately after a set_xxx_variables().

[kyllingstad]

An alternative would be to make our slave interface more explicit by expanding it with a do_iteration() function which is equivalent to do_step(0.0) in FMI 1.0 and is a no-op in FMI 2.0. I'm leaning towards this solution.

[kyllingstad]

Also worth noting is that mock_slave (in test/cpp/mock_slave.hpp) does not adhere to an FMI 2.0-like interface in this regard. It does not update any outputs unless do_step() is called.