What finally worked

I have a quad core machine at my desk so I run multiple MATLAB windows.  These multiple windows allowed me to test some distributed computing processes.  As a result I set up a script for allowing the multiple windows to run.  I was using Stateflow in the model which requires a compile before each run.  As a result the model had to be run from a temporary directory.

This temporary directory was the first sign that the function, when distributed, is working.  The second sign was when the output file is saved.

Long story short, the batch command worked.  The batch command works but only with the PathDependencies and FileDependencies properties set.  The function is something like this

jj = batch(‘monte_sim_loop’, ‘matlabpool’, 0, ‘PathDependencies’, {…}, ‘FileDependencies’, {…});

The matlabpool set to 0 is important.  I tried to using a matlabpool of 3 for my initial runs.  It tied up 4 nodes but only run 1 instance of the sim.  Then I created a loop

for ii = 1:15

  jj = batch(…

end

The reason that a matlabpool of 3 tied up 4 nodes was that the matlabpool property is for how many additional nodes you want running.  It originally appeared to be an overhead function that was created.  A coworker discovered the matlabpool command already assumes 1 node and so anything higher than 0 ties up that many extra PCs for the 1 job task.  Since I just want my jobs distributed (not parallel) I set the property to 0.   When I ran the loop above, 15 computers were tied up and 15 nodes worth of results were produced.

If you know more, please share

I invite anyone and everyone who knows more about how to use the Parallel Computing Toolbox to share.  Use the comments to share.  Or if you like I welcome guest bloggers.

Thanks

Previous, related, posting

MATLAB’s Parallel Computing Toolbox First Impression

Monte Carlo Runs

For work I’ve been asked to run a Monte Carlo analysis.  The analysis is one where I vary a large set of parameters in a large Simulink simulation.  Any given simulation will take between 40 minutes and a few hours.  So obivously generating thousands of runs with a single computer would take months.

In the lead up to this analysis I asked a few questions.  First, I found a bank of parallel computing resources at work.  I asked them if it was possible and the answer was “Yes” with my take away being that it was doable and easy.  It may be doable, it is not easy.  Second, I went to Mathworks training (on modeling for aerospace system which had a session on parallel computing) and asked some questions about how to run parallel operations.  I also left this session thinking it would be easy.

The online help is worthless

When you are running a model of any complexity there are a lot of parameters to set.  If you are building models correctly you will be setting these parameters via variables not hard coding.  This means that the simulation workspace must have all those variables.

The Mathworks help with regard to the Parallel Toolbox and Simulink simulations is pretty meager.  One of the easiest means of distributing the simulation is through the use of the parfor keyword instead of the for keyword.  The meager help suggests that simulation must be run from within a function because parfor requires a static workspace and Simulink creates variables in whatever workspace it runs from.  So the help suggests using a dummy function as a wrapper for the sim command.

The help forgets to mention that running a simulation from a function’s workspace is simple – once you find that help but finding that help was a little buried.  (If you want to know how look up the simset function and the SrcWorkspace and DstWorkspace properties.)  I have run several simulations from within a function’s workspace on a single PC.  However, doing so from within a dummy function called from a parfor loop doesn’t work like it does from a single PC.  And the error messages are obtuse.

Obtuse Error Messages

I spent days attempting to get the simulations distributed to the various nodes.  The error messages provided at this stage were reasonably straight forward.  However, once the simulation was distributed to the nodes the error became far less useful.  The first couple of times there was no obvious error.  After digging through a long log file a cowroker found the errors and helped me fix them.  That said, I think they were listed as warnings in the log file not errors.

Next Post:  What finally appears to have worked

Control System Modeling: Purpose

I’m going to use model and simulation as synonyms in this post.

The purpose of modeling in any discipline, including control systems, is to answer a question; often a very specific question is answered.  There are several reasons for why any given model only answers a small set of questions.  Budget and Schedule.

Modeling Complexity

Budget and schedule force engineers to model only those aspects deemed necessary to answer the question posed.

Modeling the universe in detail – even the very localized universe around a small object – takes a lot of work and time.  Budget and schedule concerns always force engineers to start with first principles and then model progressive deeper levels of details and fidelity.  The deeper layers are only modeled if the desired level of result accuracy requires this extra fidelity.

There are several reasons for keeping a model as simple as possible:

1. Initial time to development goes up with complexity
2. Time required for maintanence goes up with complexity
3. Odds of a mistake go up with complexity
4. Time between simulation start and delivery of results goes up with complexity

My observation is that items #1 through #3 increase roughly exponentially with complexity.  Turn around time (#4) increases but the amount of increase is highly dependent on the slowest part of the model as it exists prior to the increase in fidelity.

Control System Modeling: Pitfalls

Expanded Purpose

Engineers and other professionals who do not create or run simulations on a regular basis often forget about the narrow focus of a good model.  As a result these people often ask for results the model is not designed to produce.  Obviously the engineer being asked for the results needs to consider the request very carefully.  There may be an assumption built into the model which invalidates its use for this expanded purpose.

Juggling Programs

Each day that I work on a model I go through a process of “loading my RAM” or short term memory.  In order to work on the model and produce meaningful results a certain number of details and parameters must be loaded up into short term memory.  I find this process takes no more than 30 minutes and rarely takes more than 45 minutes.

The pitfall is in assuming you can juggle certain types of work.  Last summer I was asked to juggle modeling work and hardware maintanence work.  The hardware work needed me for 30 minutes at a time about 4 or 5 times a day.  As a result the hardware work repeatedly interrupted my efforts on the modeling work.  The interruptions came about every hour and a half.  So I used half of my time in between “loading my RAM”.

After about 2 or 3 weeks of trying to juggle the hardware and the modeling work I realized I was never gonig to get anything done on the model if I didn’t set some limits.  I asked the two programs how they wanted me to handle the problem.  The basic response was just deal with it.  So I decided to tell the hardware guys that 2 days a week they couldn’t bother me, except for emergencies.  No one was happy but it was the best I could do.