General information

To use Matlab, you need to load the appropriate module for the version you want to use. The following example shows how to load the MATLAB module (the $ is the prompt; do not type it).

$ module load matlab

To use a specific version, check which versions are available with this module command.

$ module available matlab

Then load the version you want. Please see our page on Lmod for more information on loading modules.

To run MATLAB at a prompt, simply type

$ matlab

that will start either a text-based interface or the desktop if an appropriate display is defined.

The cluster is designed to run jobs in the background. To run a MATLAB script, from the the command line, use MATLAB’s -r option, as in this example which runs the program in the file my_simulation.m from the current directory.

$ matlab -r ./my_simulation

You may run MATLAB on a login node so long as it does not consume a lot of memory or CPU cycles. In general, that means only working with smaller amounts of data and not running programs that do a lot of computing. Running small, test cases to verify syntax and check viability are OK, but you should submit a job for larger and longer running jobs. As a guideline, you should not use more than 4 GB of memory, and your program should not run more than 5–10 minutes without pause.

In general, the cluster does not provide a graphical interface, and jobs will run without interactivity. You should, therefore, set up your MATLAB scripts to run when invoked on the command line.

Suppose you have a MATLAB program called my_simulation.m.

To test whether it will run within a job, you should first make sure that you have scaled it down to the allowable run time and memory, then test it with the command you will put into your submission script, which will usually be

matlab -nodisplay -r ./my_simulation

Note that the MATLAB script that you run should have an exit command in it. If your MATLAB program does not contain an exit, when it completes, MATLAB will remain active but idle until all the requested walltime for your job has elapsed.

If your program does not contain an exit, you can supply it on the command line with

matlab -nodisplay -r "./my_simulation ; exit"

and note that the quotes are required. If your my_simulation.m script can be invoked with arguments, say the number of iterations and mesh size as the two arguments, you can also pass those on the command line with

matlab -nodisplay -r "./my_simulation(2, 10)"

and again, the quotes are required to keep the parantheses from being interpreted by the shell.

Parallel computing with MATLAB

There are several ways to do parallel computing with MATLAB. To use parallel computing, a cluster profile must be defined. By default, MATLAB defines a local profile that contains all the processors that are available to it on the physical machine on which MATLAB is running. On a login node, that will be all the processors, whereas within a job, that will be the number of tasks requested.

Using the local profile

The local profile always exists. You can start a pool of parallel workers using the local profile with the following MATLAB command which assumes that the number of workers has been saved in the variable NP.

thePool = parpool('local', NP);

The name of the pool object, thePool can be changed if you prefer a different name. At the end of your MATLAB script, you should always include a


This insures that any status information about the running pool is cleaned up and does not cause a problem for future uses.

Using the current profile

The current profile is used when you want to use the resources provided to the job by SLURM. First, you need to run the script that obtains the current SLURM resources; next you need to set the number of processors available to the job; finally, you create the pool of parallel workers. Here is an example.

%%%%  Initialize the Umich Cluster profiles

%%%%  We get from the environment the number of processors
NP = str2num(getenv('SLURM_NTASKS'));

%%%%  Create the pool for parfor to use
thePool = parpool('current', NP);

As with the local profile, you should always delete the pool at the end of your script.