search

ALSETLab / RaPId

RaPId (a recursive acronym for "Rapid Parameter Identification") utilizes different optimization and simulation technologies to provide a framework for model validation and calibration of any kind of dynamical systems, but specifically catered to power systems.
GNU Lesser General Public License v3.0
40 stars 12 forks source link

Avoiding the Simulink Container #4

Closed lvanfretti closed 8 years ago

lvanfretti commented 8 years ago

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.

janlav commented 8 years ago

I am not sure if this issues is present in the current version:

  1. There is an option to simulate the FMU directly in RaPId using Matlabs ODE-solvers, this can be done both in GUI (easily) and programatically (changing the corresponding fields in the RaPIdObject.
  2. Using Simulink seems to be faster than ODE in our experience for the newer versions of RaPId. There is no opening or closing of the simulink-file between iterations. We now can run Simulink without displaying the Simulink-diagram or the scopes. Simulink (and hopefully ODE) should also allow parallellism in future versions of RaPId.
MaximeBaudette commented 8 years ago

@lvanfretti I propose that you ask Jan or Giuseppe to show you the latest development concerning the interaction with Simulink and the integration of the Matlab-ODE solver. If it answers you request, we will close this issue

lvanfretti commented 8 years ago

@janlav I think we need to run a test of using a simple piece of code that calls either ODE or Simulink repeatedly and check the performance for one test model, just by doing simulation using inputs, not the whole RaPId process.

If the test shows that performance is not affected, then it means that the simulation part is not affected by Simulink.

MaximeBaudette commented 8 years ago

@lvanfretti After discussing with @janlav, it seems that the enhancement you described is already implemented in the toolbox. Therefore I will close the issue. As you are interested in comparing the two modes, I will move this to Trello to keep track of what test are left to do with the toolbox. My intention is to keep the issue tracker focused on resolving the problems inherent to the toolbox, and not use it as a project management tool.