Open dirk-runge opened 1 month ago
Can you share steps to reproduce the problem?
I found out that there is a race condition in the master program that can lead to the communicationPoint being incremented before it was processed by the FMU. Since multiple threads are involved, this also explains why the issue appears at random simulation times.
However, I was (mis-) lead to believe that the reference FMUs are at fault because there actually is a similar / related problem when running them in FMPy. To reproduce the problem, you just need to set unusually long simulation times and sooner or later the communicationPoint mismatch will appear. When re-running the simulation, the mismatch will appear at exactly the same time as before. However, when restarting FMPy (the Python process, not just the simulation) the mismatch will appear at another time.
The
Feedthrough.fmu
(for FMI 2.0, version 0.0.30) reports communicationPoint mismatches at random times in the simulation. For example:Expected currentCommunicationPoint = 11958.34 but was 11958.35.
The CoSimulation runs with a fixed step size of 0.001s. The master calculates the communication point by
iteration * h
i.e. no numeric noise is accumulated. If this is a problem due to numeric inaccuracies, I would expect the error to appear always at the same time in the simulation (once the added-up inaccuracies have become larger than some threshold). However, this is not the case. The problematic communicationPoint is different each time the simulation is run.At first I thought that there might be a problem with my simulation master implementation but when I run the FMU in FMPy, it shows the same problem. Hence, it's more likely that the implementation in the FMU is not correct or not tolerant enough.