adapt fmi4cpp for distributed systems

[prudhomm]

When deploying thousands of instances of the same FMU (Functional Mock-up Unit) in a distributed system using MPI (Message Passing Interface), it is inefficient for each MPI process to unzip the FMU individually. This pull request introduces an option to control whether the FMU should be unzipped or not. Typically, the MPI process with rank 0 will unzip the FMU once, and the other processes will wait until the FMU is ready to be loaded. This approach reduces redundant file I/O operations and improves initialization performance in large-scale distributed simulations.

• closes Enhance FMU Constructor for Distributed MPI Environments feelpp/FMI4cpp#1

[markaren]

I think this PR can be simplified. If fmupath extension .fmu, unzip, if is_directory assume unzipped folder. No need to add the boolean flag.

[prudhomm]

@markaren the boolean is necessary if we let the fmu class load the fmu. the unzipFMU is there for the distributed to avoid unzipping hundreds or thousands of the same fmu.

so in parallel using MPI say, (or multithread for that matter)
rank 0 MPI process would

fmu::fmu(path, mpirank == 0 ); // only rank 0 unzips, the other will read the unzip directory and load the dll

does that make sense? The use case is really parallel computing.

[markaren]

I was thinking that the FMU was unzipped by the user prior. But that function may not be exposed through the public API. That could be a solution though. Expose an unzip function for the user to control. What would be the best solution?

[prudhomm]

I think exposing the unzipping function would be more explicit and probably better in the end.
people might not understand why we provide this boolean flag.
so the path to the fmu would be in mpi the unzipped directory and fmu::fmu is kept simple.
However the name of the fmu path should be known by all MPI processes afterwards so that they load correctly

[markaren]

However the name of the fmu path should be known by all MPI processes afterwards so that they load correctly

Yeah, a solution to this is needed. This PR has issues with that as well. Moving the issue to user-land lets the user deal with it.

[markaren]

Anyhow, I exposed unzipper in 38799be