Alternative to Concurrenc​yResolving​ToFileSuff​ix when using sim in Normal or Accelerator Mode

I'm looking for an alternative to using ConcurrencyResolvingToFileSuffix, which is only available in Rapid Accelerator Mode, while using sim in Normal or Accelerator Mode in a parfor-loop. I need to run multiple (upwards of hundreds) of simulations from a final SimState, which does not allow Rapid Accelerator Mode. I'm writing my data using To File blocks and a generic name according to the signal bus, which should ideally have a simulation scenario appended to the file name. The only solution I can see to avoid the issue of writing to a single file name during parallel computing is to use parameters and set_param to change the file names in the To File blocks according to the simulation scenario (i.e. the parfor-loop index).

SimState is entirely necessary at this point, as I'm running Simscape Power Systems (SPS) and need to initialize custom built dynamic models via simulation. The root of the problem is that I am unable to (or at least unaware of how to) initialize my custom models using load_flow in SPS, hence the need for SimState.

Answer 1

[Sanjay Nair]

Hello Jason,

Using a sim in parfor workflow, the way I know to solve the problem of avoiding the overwriting of files written with To File blocks is exactly as you say: use the set_param command and change the block parameter for each iteration.

If you're using MATLAB version R2017a you can use the parsim command: https://www.mathworks.com/help/simulink/slref/parsim.html It will automatically avoid the overwriting of files specified in To File blocks and also supports the use of initial states via the SimulationInput object setInitialState command.

[Jason Zrum]

Hi Sanjay,

I ended following the recommendation under "Resolving Data Concurrency Issues" at https://www.mathworks.com/help/simulink/ug/running-parallel-simulations.html#br93zu8. It is easy to create a separate folder, with a unique name, to save the .mat files within the parfor loop. After creating a unique directory, I can change into the new directory and run the simulation. At the end of the simulation I can change back to the original directory. This keeps the body of the parfor loop independent, but also prevents data concurrency.

I actually prefer this method over changing the block parameter for each iteration, as it prevents saving potentially thousands to hundreds of thousands of files to a single file directory.