During the initial design of RaPId, my intention was to avoid completely the Simulink "container".
However, we didn't really know what would be the use of RaPId with Achour, and we though the container would give users flexibility. But now that some people is using RaPId for problems that require > 1,000 simulations, I think the Simulink container is making things slow and therefore we are sacrificing too much performance for the sake of flexibility.
So, I think we can set this issue for someone to take care of it - the idea is to "add" a functionality that allows to define the inputs and outputs via script (we already can define parameters programmatically) - and in this way utilize the function from the FMI toolbox that allows to call the FMU directly.
The reason is that it adds a lot of overhead, as each time that a simulation is executed, the Simulink model is opened, simulated, and then closed. Instead, it is possible to avoid the Simulink container if we could instead find a way of specifying inputs and outputs for a given FMU directly in a script.
This functionality would be of great value once someone has done some work and knows exactly what outputs to be used. I think we would decrease the execution time at least by 1/2 for the models.
The container is also used for visualization of the iterative process, but this could be enabled through a simple plot when the inputs and outputs have been defined through scripting instead of the FMI Block.