Closed ghorwin closed 2 years ago
I do believe this should be an implementation detail of the application itself. Thanks for the heads-up though.
Sorry, but that just won't work. See, when you have a slave with OpenMP parallelization, and you need to have had spin-down after each and every call to the slave (because the master may choose to call terminate in the slave at any time and instance), you add about 100 ms to each fmi2call, which would be a bit of an overhead. Actually, for my application, the OpenMP thread collective is maintained throughout the entire master calculation process, for the master being to fast (see MasterSim).
But it all boils down to a question, how robust you want to make the master code against careless/sloppy FMU implementations or if you're ok with occassional crashes at the end of the simulation. In any case, just wanted to point that issue out because I had problems with it.
and you need to have had spin-down after each and every call to the slave (because the master may choose to call terminate in the slave at any time and instance), you add about 100 ms to each fmi2call, which would be a bit of an overhead.
Why? I'm not into OpenMP, but I assume it is similar to a thread pool. Wait for the pool to to finish (using a proper API function, not sleep) during the call to either terminate or freeInstance. Problem solved.
This is on the FMU implementer, as it should be.
Just something I've found necessary in my FMI implementation (see MASTERSIM), when we have FMI with OpenMP loops, you need to add a delay of some milliseconds to allow the openmp thread pool to collapse. While this is something that could be done by the application itself, see:
https://sourceforge.net/p/mastersim/code/HEAD/tree/trunk/MasterSim/src/MSIM_MasterSim.cpp (line 1531)
you may want to add this to the library to avoid these problems for users not aware of the issue.