open-simulation-platform / libcosim

OSP C++ co-simulation library
https://open-simulation-platform.github.io/libcosim
Mozilla Public License 2.0
61 stars 10 forks source link

Sampling period for computing the rolling average real time factor #758

Closed davidhjp01 closed 6 months ago

davidhjp01 commented 6 months ago

When the simulation step size is too small, e.g. 0.001, a fixed cosim::real_time_config.steps_to_monitor value would not be sufficient to compute the rolling average real time factor because of the following scenario:

  1. Set steps_to_monitor to a large value (1000) because the default 5 is too small window size to accurately compute RTF.
  2. Set the simulation step size to 0.001. The solution is good enough when the simulation can keep RTF 1.
  3. When RTF drops, for ex. to 0.01, during the simulation for some reason, user would only see the updated RTF after 100 seconds.

To avoid this problem, cosim::real_time_config.sampling_period_to_monitor is introduced. It sets a sampling period in second(s) used in the rolling average real time factor calculation. When the value is greater than zero, the real time factor is computed periodically using the specified time instead of the steps_to_monitor value.

davidhjp01 commented 6 months ago

@kyllingstad Two things I updated: 1. Using std::is_same to check if cosim::time_point::period and Time::time_point::period are the same type. If that is the case skipping duration_cast. 3. Using int for sampling_period_to_monitor.

I found that using duration type for sampling_period_to_monitor slows down the simulation quite a bit on my use-case (small step sizes) because seems the duration instance needs to be copied on every step (via load) for the hash computation. So I would like to keep it as int type indicating millisecond for now.

Also additional duration_cast was quite an overhead. So trying to check the types are equal (e.g. nano) and if that is the case skipping duration_cast (this assumes the standard uses the same period type for the returning value when all time_points in the expression also has the same period type?).

Seems the problem was due to my local PC. Will try the original suggestion.