MATLAB: Are changes to the Simulink model not reflected between successive runs of the distributed task using the Distributed Computing Toolbox

dctMATLAB Parallel ServermdceParallel Computing Toolboxsimulink

I have written a distributed computing task that runs my Simulink model on a cluster of worker machines. In between runs, I make changes to the parameters in my model on the client machine before re-running the tasks to run the updated the model. However, the changes to my model are not being propagated to the cluster, as the workers return results based on the original model settings.

Best Answer

This behavior is reproducible without the Distributed Computing Toolbox and Engine. If you open the model in two instances of MATLAB and make changes in one instance, the changes will not be reflected in the other instance until you close and re-open the model. In order to work around this in the distributed computing environment, you can use one of the following options:

1) Modify the task to close the model (if open) and reopen it before running it.

2) Use the "RestartWorker" property of the task to force the worker session to restart (thus clearing the model from memory). For more information on this property, type the following command at the MATLAB command prompt:

web([docroot,'/toolbox/distcomp/restartworker.html'])

Related Solutions

MATLAB: Do I see an increase in memory usage on the workers as I keep running jobs successively when using the Distributed Computing Toolbox

The DESTROY command in the Distributed Computing Toolbox removes the job object reference or task object reference from the local session, and removes the object from the job manager memory.

destroy(obj)

However, when a job is finished, it remains in the job manager even if you clear all the objects from the client session. The job manager keeps all the jobs it has executed until you restart the job manager in a clean state.

Additionally, tasks running on the workers may have allocated memory that is not released: global or persistent variables, locked functions, memory leaks or persistent data in MEX files, etc.

After destroying the job or task, you can restart a worker using the RestartWorker property. The memory is then returned to the worker.You can set RestartWorker to true (or logical 1) if you want the job to restart the MATLAB session on any workers before they evaluate their first task for that job.

For example, submitting the following job after your main jobs have finished will force all the workers to restart their MATLAB instances:

     function forceRestartAllWorkers(sched)
       %After this function completes, the MDCE will have 
       % restarted each worker.   The argument 'sched' should
       % be a scheduler object, that is, the result of
       % a findResource operation.
       memFlushJob = createParallelJob(sched, 'RestartWorker', true);
       t = createTask(memFlushJob, @() true, 0, {});
       submit(memFlushJob);
       waitForState(memFlushJob);
       destroy(memFlushJob);
end

More information about this can be found at the following URLs:

<http://www.mathworks.com/help/releases/R2010b/toolbox/distcomp/restartworker.html>

MATLAB: How many MATLAB Distributed Computing Engine worker sessions should I run on the cluster

You can run as many MDCE worker sessions on a machine as you want to, but the question is whether you gain any enhancement in performance by running more workers. This issue depends on many factors, such as

- How fast is the processor speed and how much memory does each machine have?

- Are the tasks computationally intensive, or do they involve a lot of idle time?

- Is there a lot of data transferred across the network for each task?

- How does the execution time of the tasks compare to the time to transfer data?

Without this specific information, you cannot derive a clear formula about the number of worker sessions to run on your machines. But a general guideline for forming a basis for comparison is to run one MDCE worker session per processor or core. So on single-processor/single-core machines, start with one worker session; on dual-processor/dual-core machines, run two workers; etc.

Starting with MATLAB 7.4 (R2007a), it is possible to configure MATLAB to use multiple threads to perform computations. In MATLAB Distributed Computing Engine, this behavior is disabled. As a result, you should still use the general rule of one worker per processor/core.

How many schedulers you should run and how many workers should be registered per scheduler depends on how many workers you need to perform the jobs of your application. You need to register at least the minimum number of workers needed for your job with a single job manager or other third-party scheduler. Given that, you can configure your workers and schedulers in whatever ratio works best for your cluster. Generally, you minimize the number of idle workers by minimizing the number of schedulers. If all your jobs are submitted to the same scheduler, that scheduler can make best use of all available workers. It does not matter how many client sessions connect to a job manager; it makes no difference to the job manager if it receives many jobs from each of a few client sessions, or a few jobs from each of many client sessions. The same applies to schedulers other than the job manager.

Best Answer

Related Solutions

MATLAB: Do I see an increase in memory usage on the workers as I keep running jobs successively when using the Distributed Computing Toolbox

MATLAB: How many MATLAB Distributed Computing Engine worker sessions should I run on the cluster

Related Question