parsim with fast restart does not update variables set in through a PreSimFcn

I have noticed that base workspace variables supposed to be set through a PreSimFcn are not updated for a simulation when running multiple simulations using parsim() with fast restart to accelerate execution.

In my setup, the base workspace variables for each simulation are set by different MATLAB 'run scripts' specified through a cell input ('file') to the SimulationInput object's PreSimFcn as

for casenumber = 1:NumFile
    simIn(casenumber)=Simulink.SimulationInput(model);
    tmpSimIn = simIn(casenumber); % Use a temporary variable for the SimIn element to avoid runaway memory usage when using a preSimFcn with parsim
    preSimFcnInputs = {file{casenumber}, tmpSimIn};
    simIn(casenumber)=simIn(casenumber).setPreSimFcn(@(x) parsimPreSimFcn(preSimFcnInputs));
end

The PreSimFcn evaluates the 'run script' as

function parsimPreSimFcn(PreSimFcnInputs)

simIn = PreSimFcnInputs{2};
runScript = PreSimFcnInputs{1};
% Run the run script
eval(runScript)

end

I then run the simulations in parallel using

simOut=parsim(simIn, 'TransferBaseWorkspaceVariables','on','UseFastRestart','on');

When running on 6 workers, I noticed that the 10th simulation had the same parameters as defined by the 'run script' of the 4th simulation. I suspect fast restart is causing this, as the 10th simulation would start on the same worker as the 4th simulation when using 6 workers. I am running MATLAB R2020b

[Paul]

Hi Afzal,

What is the purpose of passing in simIn as PreSimFcnInputs{2}. Is simIn used in runscript?

Does runscript use evalin and/or assignin to create new variables in the base workspace of the worker?

Would your hypothesis not also apply to 7th, 8th,and 9th simulations on the 1st, 2nd, and 3rd workers (or whatever workers they run on)?

[Afzal]

Hi Paul,

Yes, simIn has got some variables assigned to it using setVariable. These are extracted in the PreSimFcn, and assigned to the base workspace.

The runscript does use assignin to create new variables in the base workspace of the worker.

I think my hypotheses about fast restart causing the issue is wrong, as running without it also causes the issue. I think the issued is caused by an external program run by an S-function in the model crashing. The 10th simulation actually has an error (simOut(10).ErrorMessage = '.../PhoenixEngineModel' has an invalid sample time. Only constant (inf), inherited (-1), or periodic (0.025) sample times are allowed in the periodic function-call block '.../Function'.

It looks like the 10th simulation does not actually start, as there is a call to a function in the model to delete a temporary file ('.busy_10') when the simulation time equals 0.005, as shown in the screenshots below. This file does not get deleted, so that I guess thay must mean the simulation did not start.

What is strange then is that the external program continues to run with the data from the 4th case.

[Paul]

Sounds like this question is now OBE, at least insofar as you think you really have a different problem.

But my next suggestion/question was going to be, why use the base workspace at all? Why not just set all the variables needed for simulation in the simIn using setVariable? I'm not sure if there is an advantage to one method over the other, thouhg using setVariable seems cleaner (to me) and th simIn object can be saved so you know exactly what you ran.

[Afzal]

I think the problem was that the variables set using setVariable were not available to function callbacks

[Afzal]

Any ideas why I might be getting the invalid sample time error? Does that indicate the model has not initialised properly?

[Paul]

All I can see is that the error message is telling you that the block PhoenixEngineModel doesn't have a valid sample time, of which there are only three. What is the sample time parameter of that block and how is it set?

[Afzal]

Hi Paul,

I managed to figure out what was causing the issue. It's logging too many parameters to workspace. It seems like it was running out of memory, which was causing Simulink to crash. I was logging 1735 additional parameters compared to a previous run when everything ran fine. By the time it got to the 10th case, it would have had 258,900,170 additional rows of data in the SimulationOutput object, based on the length of each simulation.

I re-ran the same cases without these additional parameters being logged, and it all ran fine.

Have you come across this issue before? Any ideas on what could be done about this, other than just logging fewer parameters to the workspace?

Thanks,

Afzal

[Paul]

I have not run across this issue before but have often wondered if there is a limitation on logging variables in large scale simulations.

Suggest a thorough read starging from Save Runtime Data from Simulations; in particular, check the section on "Big Data" which seems to be specfically on point for this problem.