Skip to content

matlab: Matlab numerical computing environment

Overview of package

Package: matlab
Description: Matlab numerical computing environment
For more information: https://www.mathworks.com/products/matlab.html
Categories: SoftwareDevelopment
NumericalMethods
License: Proprietary (ARRAY(0x55c016a18818))

General Usage

MATLAB (Matrix Laboratory) is a multi-paradigm numerical computing environment and proprietary programming language developed by MathWorks. MATLAB allows matrix manipulations, plotting of functions and data, implementation of algorithms, creation of user interfaces, and interfacing with programs written in other languages.

This module will add the matlab command to your PATH.

MATLAB is proprietarily licensed software. It is made available to UMD users through a Total Academic Headcount provided by the Division of IT and funding from various colleges.

Available versions by cluster

This section lists the available versions of the package matlabon the UMD HPC clusters.

Versions available on the Zaratan cluster

Version Module tags CPU(s) optimized for GPU ready?
2020b 2020b x86_64 Yes
2022b 2022b x86_64 Yes
2021b 2021b x86_64 Yes
2024a 2024a x86_64 Yes

Running a MATLAB script from the command line

While most people use MATLAB interactively from the GUI, there are times when running a MATLAB script from the command line (or from within a shell script) is advantageous. E.g. when submitting a MATLAB calculation to an HPC cluster.

To do this, you should start with a file containing the MATLAB commands you wish to run, one MATLAB command per line. You then need to:

  1. Launch MATLAB without the GUI, etc.
  2. Get MATLAB to start running your script, and exit when your script is done
  3. Get the output of the MATLAB command saved to a file

The first part is handled by running the matlab command on the command line with the -nodisplay -nosplash options. The -nodisplay option disables the GUI, the -nosplash option disables the MATLAB splash screen that normally would be displayed before the GUI starts up. You might wish to also add the -nojvm flag --- this will prevent the startup to the Java Virtual Machine, which often is not needed in these cases. Disabling the Java Virtual Machine will allow MATLAB to startup faster, but will also prevent the use of Java commands in that MATLAB session.

The second step is handled by using the -r option to the matlab command on the command line. It specifies a MATLAB command which the MATLAB session should run when it starts up. You can give any valid MATLAB command here, but typically you just want to tell it to read MATLAB commands from your file, and then to exit when it is finished processing all the MATLAB commands from the file. Typically this would be something like 

matlab -nodisplay -nosplash -r "run('./myscript.m'); exit"

The -nodisplay and -nosplash arguments disable the GUI/splash screen as discussed previously. The -r argument gives the command MATLAB should run on startup, in this case execute the MATLAB commands in the file myscript.m located in the current working directory, and then exit.

Warning

Do not forget the 'exit' command. If that is omitted, after MATLAB finishes processing all of the MATLAB commands in the myscript.m file, it will just sit at an input prompt waiting for additional commands (that will not be coming). This means that the job will not end when MATLAB finishes the calculations, but only when the Slurm maximum walltime limit for the job is reached. This will waste HPC resources and SUs in your allocation.

The third step in the process is handled with standard Unix file redirection.

Putting it all together, if you wanted to have a shell script launch MATLAB, run the MATLAB commands in a file myscript.m located in the directory ~/my-matlab-stuff, putting the output from the calculation into a file myscript.out in the same directory, you could do something like

#!/bin/bash

# Ensure module command is defined
source /etc/profile

# Load the MATLAB module
module load matlab

# Set working directory to ~/my-matlab-stuff
cd ~/my-matlab-stuff

# Invoke MATLAB, saving output to ./myscript.out
matlab -nodisplay -nosplash -r "run('~/myscript.m'); exit" > ./myscript.out

MATLAB and HPC clusters

MathWorks currently provides two products to help with parallelization of MATLAB calculations:

  1. Parallel Computing Toolkit (PCT) : This provides support for parallel loops via the parfor command, as well as some CUDA support for using GPUs. It does not provide support for MPI, but with the large number of cores available on recent CPUs, this is generally not needed for most calculations. So the PCT usually suffices for most calculations.
  2. MATLAB Parallel Server (MPS) (known as MATLAB Distributed Compute Server (MDCS) prior to 2019): This product extends MATLAB desktop workflows to HPC cluster hardware, allowing you to submit MATLAB jobs from a MATLAB session on your own workstation. It also provides support for MPI but this is generally not needed on modern CPU architectures.

Built-in multithreaded functions

A number of the MATLAB built-in functions, especially those related to linear algebra and numerical evaluation, are multithreaded and will automatically parallelize over multiple threads. As it is thread-based, such parallelization is limited to a single node. So your job script should normally instruct Slurm that you want all of your resources for the job on the same node (see documentation on specifying cores and nodes ).

For example, it your MATLAB code is in the file myjob.m and should perform well with 12 CPU cores, you might use a job submission script like:

#!/bin/bash
#SBATCH -t 2:00
#SBATCH -c 12 # Request 12 CPU cores per task
#SBATCH -n 1 # Request a single task (this is the default, can be omitted)

# Make sure module command is available
source /etc/profile

# Run matlab.  Output will be in the slurm-*JOBNUM*.out file
matlab -nodisplay -nosplash -nojvm -r "run('myjob.m'); exit"

and your MATLAB script (e.g. myjob.m) should contain the line

    maxNumCompThreads(12);
somewhere near the beginning. This restricts MATLAB to the requested number of threads --- if it is omitted, MATLAB might try to use a thread for every core it detects on the node it is assigned to, which on current clusters is typically much larger than 12. As your job will be restricted to the 12 cores requested by the sbatch command, this could result in serious performance degradation.

Parallel Computing Toolbox (PCT)

The MATLAB Parallel Computing Toolbox allows you to parallelize your MATLAB jobs, to take advantage of multiple CPUs and/or CPU cores either on your desktop or on an HPC cluster.
This toolbox provides versions of some built-in MATLAB functions optimized to support parallelization via multi-threading, as well as the parfor command to run loops in parallel.

% Allocate a pool with 20 threads
parpool("Threads", 20)

% Pre-allocate a vector
A = zeros(1,1000000000);
xfactor = 1/100;

% Time ourselves with tic/toc commands
tic
% Assign values to the vector in a parfor loop
parfor i = 1:length(A)
    x = xfactor * i;
    A(i) = x * sin(x);
end
toc

Assuming the above MATLAB script is in a file named parfor_test1.m in the directory $HOME/scratch, we can submit it via sbatch and the following job submission script:

#!/bin/bash
# Request 20 cores on a single node
#SBATCH -c 20
# Request 5 minutes of wall time
#SBATCH -t 5

# Ensure we have the module command
source /etc/profile

# Load the matlab module
module load matlab

# Run MATLAB
matlab -nodisplay -nosplash -nojvm -r "run('$HOME/scratch/parfor_test1.m'); exit"

Warning

It is important that you specify to Slurm that you want all allocated resources on a single node, as is done above by the use of the -c or --cpus-per-task flag. PCT can only access resources on a single node; resources on other nodes would just sit idle and be wasted (along with your SUs).

MATLAB Parallel Server (MPS)

The MATLAB Parallel Server (MPS) (known as MATLAB Distributed Computing Server (MDCS) before 2019) extends the functionality of the Parallel Computing Toolbox discussed above to enable it to use resources across multiple nodes. This was of greater significance earlier, but recent computer architectures generally have sufficient cores, etc. on a single node that distributed computing is not generally required for MATLAB calculations.

MPS also supports the submission of jobs to the HPC cluster directly from a MATLAB session working on your local workstation. This allows users who are not comfortable with the Unix command line to submit jobs from withing MATLAB. While this allows for use of a perhaps more familiar environment, it does not hide all of the complexity (and adds its own complexity). In general, we recommend that most users should instead try to learn how to submit jobs using sbatch on the login nodes even if this has a slightly steeper learning curve because much of what is learned in that case is applicable for a wide range of applications one might run on the HPC cluster in the future, whereas learning to submit MATLAB jobs from within a MATLAB session running on your workstation is not trivial and the procedures learned do not readily translate to other applications you might wish to or need to use in the future. However, using MPS to submit jobs from your workstation is supported if you really wish to do so.

In order to use MPS to submit jobs from a MATLAB session running on your workstation to one of the UMD HPC clusters, the following steps are required:

  1. You will need to have the same version of MATLAB installed on your local workstation as you intend to be using on the HPC cluster. I.e., your local workstation will need to have installed one of the versions of MATLAB that is installed on the HPC cluster. While we try to keep MATLAB on the HPC clusters reasonably up to date, we do not always install both "A" and "B" releases for the same year, and we generally do not install the latest release until a month or two after it has been released.
  2. You will need to install a set of MATLAB scripts, etc. to allow MPS to talk the the relevant HPC cluster. You will need to install these scripts on your local workstation, and we cannot do this for you. We try to provide good instructions, but you need to do the work and from time to time issues may occur. You will need to install these scripts on each and every workstation from which you intend to submit jobs to the cluster. Generally you should only need to do this once per workstation (at least until you upgrade MATLAB, at which point the scripts will probably need to be reinstalled).
  3. You will need to add a Cluster Profile to enable MPS to launch jobs on the configured cluster. You will need to define at least one such profile for each cluster that you wish to have MPS submit jobs to. These Cluster Profiles are generally local to a specific workstation, but are persistant across multiple MATLAB sessions, so you could just set up a basic one for each HPC cluster once and re-use it for years. You can also, however, set up multiple Cluster Profiles for the same workstation, and use these different profiles to save custom information about how the jobs are to be sent (e.g. one profile for using the debug partition, another for a medium CPU only job, another for a large CPU only job, and maybe one for a GPU job).

Installing the MPS Slurm integration scripts

If you plan to run MATLAB on your local workstation and have it submit jobs to the UMD HPC cluster, you will need to install the scripts on your workstation as we cannot do so in this case. However, we have tried to make the process as simple as possible.

The various scripts needed are contained in the following zip file (click on the filename to download it):

Filename (download link) Version SHA256 Checksum
matlab-mps-slurm-files-2025-01-03.zip 2025-01-03 77342f362e7983da765f6b39231652c78cf993140c6b44914d42e18f124af795
matlab-mps-slurm-files-2023-06-21.zip 2023-06-21 (*Deprecated*) e8564ae3d3899ba24ef664ed9aa285e81dc94e908602bbd65c38cc740627f986
matlab-mps-slurm-files-2023-02-09.zip 2023-02-09 (*Deprecated*) c214f5413656da82cc8b98d8211081d0f6a1b3e1d22c11bb87db473e0662f897
  1. Download this file to your local workstation (i.e. the system on which you intend to run MATLAB and have it submit jobs to the HPC cluster. This file is provided as a zipfile as that should be readily usable on Windows PC, Mac, and Linux systems.
  2. If desired, verify the checksum (this will help to ensure the integrity of the file.)
  3. Extract the contents of the zipfile. Traditionally, it should be extracted under a directory named for the version of MATLAB you are running (with an "R" prefix, e.g. R2022a), under a directory named SupportPackages in your MATLAB userpath directory. This would typically be (based on OS)

OS Typical filename
Windows %USERPROFILE%\Documents\MATLAB\SupportPackagesRMATLAB-version
Mac $home/Documents/MATLAB/SupportPackages/RMATLAB-version
Linux ~/Documents/MATLAB/SupportPackages/RMATLAB-version

You can unzip the zipfile there (creating any needed parent directories), or to any other location on your system. If you expand it to another location, you need to remember that path as will need to provide it as input to the configCluster command in the creating a Cluster profile step.

Generally, you only need to do this step once per workstation for which you intend to run MATLAB on (and submit jobs to the HPC cluster). We will periodically be making updates to the scripts, but unless we tell you that this is a bug that requires downloading a later version, you should with just a single installation. The only exception to this would be if you upgrade MATLAB on your workstation; in such a case it probably best to download the latest version of these scripts and reinstall them. The default path under which to extract the files will have changed, and one of the UMD scripts contains information about the currently supported versions of MATLAB on the UMD clusters, and that likely was updated since you last installed the scripts.

Creating the Cluster profile for MPS

The next step for having MATLAB be able to submit jobs to an UMD HPC cluster is to define one or more Cluster Profiles. The Cluster Profile defines various properties of the cluster, including information about how to connect to the cluster, where various files are, and information about how to submit jobs to the cluster.

You will need at least one Cluster Profile for each cluster to which you want MATLAB to submit jobs; however you can have multiple profiles for the same cluster if you wish. When it comes time to actually submit jobs from MATLAB to the HPC cluster, you will need to instantiate a cluster object in MATLAB, and this is done using a Cluster Profile as the template. Atlhough you can set and/or override many if not all of the Cluster Profile settings in the cluster object, it can be convenient to set up multiple Cluster Profiles for the same HPC cluster which are templates for the various types of jobs you expect to run. E.g., you might have a standard profle for your typical job, along with additional profiles for jobs which need longer wall times or need special resources like GPUs or extra memory.

The creation of a Cluster Profile is done by starting up MATLAB and running the MATLAB function configCluster.

You can view previously created Cluster Profiles in MATLAB from the Parallel drop down in the Environment section of the menu bar. The Select Parallel Environment option will show (and allow you to choose one of ) the existing parallel environments --- until you define a Cluster Profile your options will be just Processes and Threads. The Create and Manage Clusters... option will open a new window allowing you to view, create, and/or edit Cluster Profiles from the MATLAB GUI.

Cluster Profiles can be created interactively (i.e. from an interactive MATLAB prompt in the GUI or command line). The process is similar either way, and we recommend the interactive approach for most users. We discuss the interactive approach first.

Running configCluster interactively

Start MATLAB on the system on which you intend to run MATLAB and have it submit jobs to the cluster, i.e. your local workstation. From the MATLAB prompt, type the command configCluster. If the command is not found on your local workstation, that suggests that either you did not download and install the MPS Slurm integration scripts and/or that you did not copy the contents of the script directory to your userpath directory. Please issue the command userpath in MATLAB, and be sure the configCluster.m and other scripts in the scripts directory of the downloaded zipfile are copied to that directory.

The configCluster command should prompt you for the answers to some questions, as discussed in more detail below. The answers to the questions can also be passed as function arguments in the configCluster command if desired (in which case you will not be prompted for the answer to parameters passed that way); e.g. to set the name of the cluster to zaratan on the command line, you could do something like configCluster(clustername='zaratan')

  1. Which cluster do you wish to connect to:. Here you specify which cluster MATLAB should be submitting jobs to. It will default to zaratan; to specify it on the command line use the parameter clusterName.
  2. The configCluster script maintains a list of MATLAB versions known to be installed on UMD clusters, It will cmpare the version of MATLAB currently being run to the list of versions for the cluster you entered above. If a match is found, the script will continue to the next step.
  3. The configCluster script maintains a list of MATLAB versions known to be installed on UMD clusters. It will compare the version of MATLAB currently being run to the list of versions for the cluster you entered above. If a match is found, the script just continues with the next step. If a match is not found, this can be a problem and the script will print out a warning listing the versions of MATLAB it believes are available on the specified HPC cluster. The MATLAB running on your local workstation must exactly match a version running on the HPC cluster for MPS to work.
    1. If the version of MATLAB you are running is older than any versions installed on the cluster, you should probably upgrade MATLAB on your workstation before setting up MPS.
    2. If the version of MATLAB you are running is newer than any of those listed, it probably means that we have not yet installed the latest MATLAB on the cluster. Please open a ticket with HPC staff requesting that MATLAB be updated. Remember to include the cluster name, the MATLAB version you are running, and mention that you are trying to set up MPS.
    3. If your MATLAB version is newer than those listed, there is a small possibility that we actually installed that MATLAB version on the cluster, but forgot to update the list of versions for the cluster in the script. This is likely the case if the version your are running is shown by the module avail matlab command. The script will prompt you asking if you wish to continue. If you answer yes, the script will assume the MATLAB version is installed and continue to create the Cluster Profile for it. That Cluster Profile will not work unless the correct MATLAB version is installed on the cluster. Please still contact HPC staff to alert them that the scripts in the zipfile are out of date. From the command line, the parameter allowUnknownMatlab can be set to either true or false to bypass being prompted for an answer to that question.
    4. If your MATLAB version is between those listed (i.e. newer than oldest version listed but older than the newest version listed, then you should upgrade the version of MATLAB on your workstation to match the lastest version installed on the cluster.
  4. Username on cluster:. Here you should be specifying your username on the cluster on which you intend to submit jobs to.
    It will default to using your username on the system you are running MATLAB on, which might or might not be correct. The correct answer should be the name to the left of the "at" sign (@) in your '@umd.edu' or '@terpmail.umd.edu' email address (note: this might or might not work for other email addresses, even for subdomains of umd.edu). Also note that usernames are case sensitive, and normally are all lowercase. or @terpmail.umd.edu email address. Please note that usernames are case-sensitive, and normally should be all lowercase. The parameter clusterUsername can be used to set this value from the command line.
  5. Please provide the path to the directory containing the MATLAB-Slurm integration scripts; .... In response to this you should enter the path to the directory where the various MATLAB-Slurm integration scripts are. For the local workstation scenario, this will default to the traditional location for the system MATLAB is running on. If you extracted the zip file to the traditional location, you can just accept the default; otherwise enter the directory where you extracted the zipfile. This directory should have a subdirectory named parallel with a subdirectory slurm beneath that. To set this from the command line, use the parameter pluginScriptDir. The script will do some checking that the correct files are found underneath the path specified.
  6. Where should MATLAB store its job files on the cluster?. MPS needs to store some files on the HPC cluster; here you should enter the path of the directory where these should be stored. This should point to a directory that exists on the HPC cluster, and to which you have write permission. (If the last component in the path does not exist but the parent directory does, a new directory with that name will be created for you.) It should be a directory which is accessible from all of the compute nodes of the cluster. The scratch/high-performance file system is a good choice for this, and by default, we choose a directory named MatlabParallelServer in your ~/scratch directory. You can use the parameter removeJobStorageLocation to set this from the command line.
  7. What should this profile be named?. Here you should enter the name which you want to call this Cluster Profile. The configCluster script is unable to overwrite an existing Cluster Profile, so this name must be distinct from any existing Cluster Profiles. The default value is "Clustername HPC". You can set it from the command line with the parameter profileName.
  8. Normally, the script will display the Cluster Profile to be created, and prompt for confirmation as to whether it should actually go ahead and create the Cluster Profile. You should verify the information presented, and it acceptable type "y" to proceed after verfying the information. If you do not like one or more of the values, type "n" (or anything other than "y") and the script would abort. If you can the parameter requireConfirmation with a value of false on the command line the script will bypass the confirmation process and create the Cluster Profile without confirmation; this also happens if the configCluster script is not invoked in interactive mode.

When finished, the configCluster command will print out some information about the Cluster Profile created. This is still a rather generic Cluster Profile --- it knows how to connect to the specified cluster for submitting jobs, but it does not have customized values for the various sbatch/job parameters and so will just use defaults. You will generally need to set the various job parameters, either after you instantiate a cluster, or in the Cluster Profile, and you might wish to have multiple Cluster Profiles for the same cluster with the common job settings.

Setting the various Cluster parameters

The basic process of having MATLAB submit jobs to an HPC cluster is to instantiate a Cluster object in MATLAB from a Cluster Profile, and then invoke methods on that Cluster object to submit jobs. These jobs, through a somewhat complicated series of scripts included in the MPS Slurm Integration scripts, actually are submitted in the end via the sbatch command. And while MATLAB builds the job script and tries to hide much of the complexity of the sbatch command, it cannot hide everything. Alt>hough the default values for many of the parameters for the sbatch command are reasonable, you will likely need to set at least some (like the wall time limit) for production jobs.

Most parameters can be set in the Cluster Profile, in which case any Cluster instance created from that profile will inherit those values, and/or they can be set (or overridden) in the actual Cluster instance. We split these parameters into two categories; a group of top level parameters and a set of parameters which are fields of the top-level parameter AdditionalProperties.

We discuss the various parameters in each category first, and then discuss how to set/modify them.

  1. List of top level parameters
  2. Fields of the AdditionalProperties top level parameter
  3. How to set/modify these parameters

Top level parameters

The following table lists the "top level" parameters. The "Class" column lists what classes of objects the parameter applies to:

  • C for Cluster objects
  • CP for Cluster Profile objects
  • J for Job objects
Parameter Name Class Type Description
Profile C+CP string The name of the Cluster Project object form which the Cluster was created
Description CP string A description of the Cluster Profile. This is for human consumption, it does not impact MATLAB performance
NumWorkers C+CP number The maximum number of workers (MPI tasks) that a Cluster derived from this profile can use. The default is infinite, but you might want to set a reasonable default. A finite value must be set before you can validate the profile. Increasing this value increases the number of workers MATLAB is _allowed_ to use; MATLAB might still descide to use less workers for your calculation. Even if MATLAB uses all of the workers allotted performance might or might not improve.
NumThreads CP number The maximum number of threads that MATLAB can use for any given [MPI task](/kb/glossary.md#mpi)/MATLAB worker. Generally, the number of [CPU cores](/kb/glossary.md#core) used by MATLAB will be the product of the number of workers and number of threads per worker. MATLAB uses different parallelization techniques depending on the calculation.
JobStorageLocation C+CP string This is where job data is stored on the client MATLAB system (i.e. the system MATLAB is submitting jobs _from_)
AdditionalProperties C+CP cell array This field structure stores a bunch of additional parameters not covered by other top level fields. This is where most of the Slurm/sbatch specific parameters go, and due to the large number of possible fields is discussed below.

The following top level parameters are generally properly set by the configCluster command and generally should not be changed, and are mainly listed for completeness.

Parameter Name Class Type Description
Modified C logical Whether of not the Cluster object has been modified since being created from the Cluster Profile. This is a read-only parameter, you cannot modify it
ClusterMatlabRoot C+CP string This is the path to the MATLAB installation on the HPC cluster. You should not need to change this.
Host C string The hostname of the client system (i.e. the system MATLAB is submitting jobs _from_). This is a read-only parameter.
RequiresOnlineLicensing C+CP logical This specifies whether the cluster requires Online licensing for MATLAB. This should be false for UMD HPC clusters
LicenseNumber C+CP string If the cluster requires Online licensing for MATLAB, this is the license number it should use. As UMD HPC clusters do not require Online licensing, this should be left set to _none_
OperatingSystem C+CP string The type of Operating system on the HPC cluster. For UMD HPC clusters, this should be set to `unix`.
HasSharedFilesystem C+CP logical This specifies whether or not there is a filesystem shared between the client MATLAB process (the one jobs are submitted _from_) and the MATLAB processes running on the HPC compute nodes. This will be false when running from your workstation.
PluginsScriptsLocation C+CP string This is the path to the directory (on the client system) where the MPS Slurm plugin scripts are to be found. You should not need to change it.

The following top level parameters are generally only needed for more advanced use cases.

Parameter Name Class Type Description
AutoAttachFiles CP logical This determines whether the client MATLAB system should automatically send the code files listed in the `AttachFiles` parameter to the HPC cluster. This defaults to true, but since `AttachFiles` defaults to an empty list nothing is transferred
AttachFiles CP+J cell array This is a list of files which the client MATLAB system should send to the HPC cluster with the job. Default is false. Most of the time, it should be left empty, but it can be useful in some cases. See MathWork's MATLAB documentation for more information.
AdditionalPaths CP cell array This is a list of directories (on the HPC cluster) which should be added to the search path for MATLAB workers. By default it is empty. See MathWork's MATLAB documentation
NumWorkersRange CP list of integers This specifies the range of the number of workers for jobs submitted via Cluster objects derived from this Cluster Profile. By default it is 1 to infinity.
CaptureDiary CP logical This controls whether the command windo output is returned. Default is false.

AdditionalProperties

As noted in the table above, there is a top-level parameter named AdditionalProperties which is a structure containing potentially a large number of additional parameters. Many of these parameters directly correlate with parameters passed to the Slurm sbatch command, and so this field is typically the one which gets the most customization. As the AdditionalProperties property is visible in both Cluster Profile and Cluster objects, these parameters can also be set/modified for both object trypes. The recognized parameters for AdditionalProperties are discussed in this section.

The following table lists parameters which are not set by the configCluster command, and basically correspond to the parameters passed to the Slurm sbatch command. You might need to add/modify these to have MATLAB submit jobs with the correct parameters.

Parameter Name type Description Sbatch flag See also
AccountName (or Account) string The name of the Slurm allocation account the job should be charged against. If omitted, Slurm will use your default allocation account. You might need to set this if there are multiple Slurm allocation accounts you have access to.    
EnableDebug logical If set, the various MPS Slurm integration scripts will produce some debugging output. Default if false    
EmailAddress string If `EmailType` is set, this is the email adress Slurm will email about job status changes. If omitted, it will default to your username with @umd.edu appended. Ignored unless EmailType is set. --mail-user sbatch email flags
EmailType string This causes Slurm to send email (to the address specified by `EmailAddress` parameter) on certain changes in job status. It takes a string of comma delimited states, without spaces (e.g. 'BEGIN,END') --mail-type sbatch email flags
Features (or Feature or Constraint) string This should be a comma delimitted list of features, w/out spaces --constraint sbatch constraint flag
GpusPerNode number This specifics the number of GPUs per node that MATLAB should have Slurm request for the job. Ignored if unset or zero. If set, it will default the partition to `gpu` and the request number and type (see `GpuCard`) of GPUs --gpus-per-node sbatch GPU flags
GpuCard string Specifies the type of GPU being requested. Ignored unless `GpusPerNode` > 0. Takes a gpu name (e.g. `a100`) --gpus-per-node sbatch GPU flags
MemUsage (or MemPerCpu) string The amount of memory requested (per CPU core). Should either be a number (in MB) or a number followed by M or G for MB or GB, resp. --mem-per-cpu sbatch memory flags
NumNodes number The number of nodes to request --nodes sbatch node and core flags
ProcsPerNode number This will set the max number of tasks (i.e. MATLAB workers) assigned to a single node. Normally we recommend leaving this unset --ntasks-per-node  
Partition (or QueueName) string The partition in which job should be run. Normally you should leave this unset unless you want to use the `debug` partition --partition partitions
RequiresExclusiveMode logical If set, this will disallow other jobs to share the same node as your job. It is recommended to leave this unset, as your allocation will be charged for the entire node. --exclusive exclusive mode
Reservation string Run job in specified reservation. Generally you should only use this if you were instructed to do so by HPC staff or a professor. Trying to use an inactive reservation or one you do not have access to will cause your job to wait in the queue forever --reservation reservations
Resources (or Resource) string This will request generic resources (GRESes) for the job --gres resources
WallTime string This specifies the maximum amount of time a job can run, typically either as a integer number of minutes or as hours:minutes or days-hours:minutes. You will usually need to set this as the default is 15 minutes --time walltime
AdditionalSubmitArgs string This is a catch-all for any sbatch flags needed not covered in the above. This should be a string of valid flags to the sbatch command, which is passed unmodified.    

The following parameters should normall be set properly by the configCluster, but they might be changable if needed.

Parameter Name type Description Changable
UserName string Your username on the HPC cluster yes
RemoveJobStorageLocation string The path to a directory on the HPC cluster where MATLAB can store job data. yes, but MATLAB might not be able to find old job results, etc.
UseUniqueSubfolders logical If set, MATLAB will store job data on the HPC cluster in subfolders of `RemoteJobStorageLocation` based on username and MATLAB version. `confgCluster` sets this to true. yes, but MATLAB might not be able to find old job results, etc.
UseIdentityFile logical If set, MATLAB will use SSH public key authentication when connecting to the HPC cluster's login node. This does not work with Zaratan. If not set, MATLAB will prompt for a password when needed (usually once per MATLAB session) no (does not work with Zaratan)
AuthenticationMode string This tells MATLAB how to authenticate to cluster. For Zaratan, it **must** be set to `Multifactor` to work. no
ClusterHost string The name of the login node MATLAB will ssh to changing not recommended

Modifying C/CP parameters

Now that we have described the various Cluster and Cluster Profile parameters, how does one go about setting or modifying them? The actual steps are a bit different depending on whether you wish to set/modify parameters in a Cluster Profile or in an actual Cluster instance. Modifying parameters in a Cluster instance does not directly affect the Cluster Profile (although as we will see later, there is a process by which you can save such changes back to the Cluster Profile), but will affect jobs submitted from that Cluster object. Modifying a Cluster Profile will affect future Cluster instances derived from that Cluster Profile, but will not affect previously instantiated Cluster objects.

Generally, we recommend setting up multiple Cluster Profiles, one for each basic job type you commonly use (e.g. maybe a Cluster Profile for a standard CPU job, another for jobs that need longer runtime and/or more memory, another for standard GPU jobs, etc). You can create the base Cluster Profile using the configCluster function, and/or duplicate existing Cluster Profiles within the MATLAB Cluster Profile Manager GUI, and then edit and customize the Cluster Profiles in the Cluster Profile Manager or from the MATLAB command prompt.

When you have custom settings needed only for a small number of jobs, these customizations can be made in the Cluster object, after instantiating it from the closest matching Cluster Profile. Generally, modifications to the Cluster object need to be done at the MATLAB command prompt. If you really prefer GUIs, you could create a temporary Cluster Profile in the Cluster Profile Manager by duplicating the closest normal Cluster Profile, make the customizations in the temporary profile, and then instantiate the cluster from the temporary profile, and delete the temporary profile when it is no longer needed.

If you have access to the MATLAB GUI, the easiest way to modify a Cluster Profile is via the Cluster Profile Manager. For parameters that are only present in Cluster Profiles and not in Clusters, this is the only way I know of to modify the parameter. It can be opened up via the Create and Manage Clusters ... entry in the Parallel drop down in the ENVIRONMENT section of the top menu bar of the GUI. Once opened, you should see a list of Cluster Profiles in the left panel, and the right panel should contain a listing of the various parameters and values.

  1. Select the desired Cluster Profile in the left panel
  2. You can make this your default Cluster Profile by using the Set as Default button in the MANAGE PROFILE section of the top menu bar.
  3. You can make a delete this profile by clicking on the Delete button in the MANAGE PROFILE section of the top menu bar.
  4. You can make a duplicate/copy of this profile by clicking on the Duplicate button in the MANAGE PROFILE section of the top menu bar.
  5. You can change the name of the Cluster Profile (the Profile top level parameter) using the Rename button in the MANAGE PROFILE section of the top menu bar.
  6. To change other parameters, click on the Edit button in the MANAGE PROFILE section of the top menu bar. This will cause the right side panel to change from display mode to edit mode. The top-level parameters can just be changed by entering the new value in the input box and/or choosing a new option from the drop-down. For the parameters which are fields of the AddtionalProperties parameter, you can
    1. Modify an existing value by clicking on the Value column for the appropriate field and either typing the new value in or selecting a new value from the dropdown.
    2. You can delete a parameter by selecting the parameter and clicking the Remove button.
    3. To add a new value, click on the Add button, and then enter the (case-sensitive) name of the new parameter, select the correct Type from the drop-down, and either type in the new Value or select it from the dropdown.
  7. When you are finished making changes to the Cluster Profile, click on the Done button to save it. You can click on the Cancel button if you wish to abort your changes without saving them.

At this time, I am unaware of any way to directly modify the parameters of a Cluster instance in a GUI fashion. You could use the Cluster Profile Manager to modify the base Cluster Profile for the Cluster (or a copy of this) to set the parameters as you desire them to be in the Cluster, then derive the Cluster from this modified Cluster Profile, and then either reset the Cluster Profile (or possibly delete it if it was just a temporary copy).

To directly modify a Cluster instance after it is created, you can do so in the MATLAB command line (or in a script), and it is reasonably simple. The "top level" parameters can simply be set in assignment commands; e.g. if the Cluster instance is in a MATLAB variable named cl and you wish to change the NumWorkers parameter to 64, you can use a code snippet like: 

cl.NumWorkers = 64

For parameters which are fields under the AdditionalProperties, the process is similar, but you need to add the AdditionalProperties property in the assignment. E.g., using the same Cluster instance cl again, to set the WallTime parameter to 4 hours and 30 minutes, you could use a code snippet like 

cl.AdditionalProperties.WallTime = '4:30:00'

To set or modify parameters in a Cluster Profile from the command line, the process is to create a Cluster instance that derives from the profile, and set the parameters for the Cluster as described above. Once everything is set as desired, you can save the settings of this Cluster instance back to the Cluster Profile with the saveAsProfile method on the Cluster instance, passing it the name of the Cluster Profile to save to (this can be the name of the Cluster Profile the Cluster was derived from, the name of a different existing Cluster Profile, or the name of a new Cluster Profile to be created). E.g., if you used the configCluster command to create a standard profile named Zaratan HPC, you can create a new profile with the same basic set up for submitting jobs to the debug partition, with up to 64 workers and a 15 minute walltime, with the commands:

% Create a Cluster instance from 'Zaratan HPC' Profile
cl = parcluster('Zaratan HPC')

% Set max walltime to 15 minutes, number of workers to 64, and
% partition to debug
cl.NumWorkers = 64
% NOTE: we set WallTime to a string value to preserve type
cl.AdditionalProperties.WallTime = '15'
cl.AdditionalProperties.Partition = 'debug'

% And save as a new Cluster Profile
cl.saveAsProfile('Zaratan: Debug partition, 64 cores')

Note that the command line/scripted approach to setting or modifying parameters for a Cluster Profile is restricted to setting/modifying parameters that are common to both Cluster and Cluster Profile instances.

Validation of Cluster Profiles

When using the MATLAB GUI, you can access the Cluster Profile Manager, which can be opened up via the Create and Manage Clusters ... entry in the Parallel drop down in the ENVIRONMENT section of the top menu bar of the GUI. Once opened, you should see a list of Cluster Profiles in the left panel, and the right panel should contain a listing of the various parameters and values. Once you select a Cluster Profile, you can click on the Validate button to cause MATLAB to run some tests on the Cluster Profile.

Note

The validation process will only run if the NumWorkers parameter is set to a finite value. Generally, the validation process is faster with smaller values of NumWorkers.

When using MPS to connect MATLAB to the Zaratan HPC cluster from your local workstation (e.g. your laptop or desktop), please ensure that you are connected to the campus VPN. Otherwise, multifactor authentication will be required and the MPS code to connect to the cluster has trouble handling that.

When the Validate button is clicked, MATLAB will start a series of five tests. Most of these tests involve the submission of jobs to the configured HPC cluster, and so these tests can take a little while. In addition to the time needed for MATLAB to compose and submit the job, there will be the time the job spends in the queue waiting for the scheduler to allocate resources to it. And the jobs themselves take some minutes to run. The time spent waiting in the queue will general increase with the resources requested, and in my experience the MATLAB overhead of collecting data from a large number of workers can sugnificantly increase the actual run time.

For jobs running on your local workstation, the first four tests should pass. The final test (Parallel pool test (parpool)) requires that the MATLAB workers be able to initiate network communications with the MATLAB process from which the jobs were launched; which in this case means that the HPC compute nodes will need to be able to initiate network communications with your local workstation. Even when the "local workstation" is on campus with a wired connection, there are often network address translation and other networking "tricks" make such communications tricky. The situation is greatly exascerbated when the local workstation is off campus or on a home network.

Note

The Parallel pool test (parpool) validation test is likely to fail when validation tests are run from your local workstation due to network issues. This test requires bidirectional communication between the compute nodes and the workstation which are usually not feasible in modern secure networks.


For this same reason, a number of parpool features will not work when launching jobs from MATLAB running on your workstation. Most users do not use these features, so this limitation does not impact most users.

So when running MATLAB on your local workstation to submit jobs to the HPC cluster, we usually consider the Cluster Profile as working properly if the first four validation tests pass.

Using MPS with an HPC Cluster

The following is a quick guide to using MATLAB Parallel Server (MPS) to submit jobs to one of the DIT maintained HPC clusters at UMD. It is assumed that you have already done the process of setting up and configuring MPS Slurm integration scripts on the system on which you will be running the MATLAB process from which you wish to submit jobs to the HPC cluster. If you are planning to submit jobs to the HPC cluster from MATLAB running on your local workstation, the scripts need to be downloaded and installed and the configCluster function needs to be run on your local workstation.
You can run configCluster more often, especially to define Cluster Profiles for specific classes of jobs you plan to submit, but at a minimum it must be run once on each local workstation you plan to submit jobs to the HPC from.

Warning

When using MPS to connect MATLAB to the Zaratan HPC cluster from your local workstation (e.g. your laptop or desktop), please ensure that you are connected to the campus VPN Otherwise, multifactor authentication will be required and the MPS code to connect to the cluster has trouble handling that.

This section discusses the various aspects of submitting jobs to the HPC cluster from MATLAB, as well as some related tasks like checking the status of the job, retrieving output, diagnosing problems, etc.

To submit a job, the basic process is:

  1. Create a Cluster instance. This is typically done with the parcluster command, saving the Cluster instance it produces to variable, e.g. cl. The parcluster command can take as an argument the name of a Cluster Profile from which the Cluster will be derived; if omitted the default Cluster Profile will be used.
  2. If you need to set any Cluster parameters for this particular job, you should set them.
  3. You now create and submit a job to the HPC cluster. The simplest way to do that is to use the MATLAB batch function; it is also possible to explicitly create a job with the createJob (or createCommunicatingJob) function, followed by the createTask and submit functions. While the latter approach gives you much more control over the job, it is also significantly more complicated to use than the batch function. For this reason, we only discuss the batch function approach in this documentation; see the reference on Detailed Job and Task Control in the MathWorks MPS links section for more information on the other approach.

First, you need to define a "cluster" to submit jobs to. This holds the information about the parallel workers, etc. For most cases, it will suffice to enter a command like: 

>> cl = parcluster;
or 
>> cl = parcluster('<var>Name of Cluster Profile</var>')

You can choose whatever variable you like instead of cl, but if so be sure to change it in the following examples as well. The first case will create a cluster instance using the default cluster profile, while the second case will use the cluster profile with the name specified as the argument to the parcluster function.

Depending on the requirements of your calculation and how much customization of the Cluster Profile you did previously, you might or might not need to configure additional parameters in this Cluster object. If you typically only have a handful of types of standard jobs that you are going to submit from MATLAB to the cluster, we recommend defining a separate Cluster Profile for each type of job; this way you can just specify the name of the Cluster Profile for the type of job in the previous step, and you can skip this step.

Some typical parameters that might need to be configured are:

  • the maximum number of workers for the job
  • the walltime for the job
  • the memory requirements for the job
  • the number and type of GPUs for the job (if it is to use GPUs)
  • the partition of the job if you wish to submit to the debug partition

Setting these and other parameters, both for the specific Cluster instance and/or for the Cluster Profile, was discussed in the section on setting Cluster/Cluster Profile parameters

E.g., to set our Cluster instance cl from the previous example to use 12 workers for a maximum wall time of 8 hours and to request 6 GB of RAM per worker, we could use a code snippet like:

>> cl.NumWorkers = 12
>> cl.AdditionalProperties.WallTime = '8:00:00'
>> cl.AdditionalProperties.MemUsage = '6G'

Finally, you should create a job for your MATLAB calculation and submit it to the cluster. This is most easily done with the MATLAB batch function. You can invoke the batch function as a method of the Cluster instance you created previously, or as a global function passing the Cluster instance as the first argument. (If you call it as a global function without passing the Cluster instance, MATLAB will create a Cluster instance from the default Cluster Profile and use that.) The next arguments tell MATLAB the calculation you wish to submit to the cluster; this can be specified as any of:

  • The name of a file containing a MATLAB script (do not include the '.m' extension). E.g. using the Cluster instance cl from the previous example, to submit the script myscript.m use either batch(cl, 'myscript') or cl.batch('myscript'). <strong>Note:</strong>myscript.m` must be in your MATLAB search path on the client MATLAB system; it will be copied if needed to the cluster.
  • A MATLAB expression. The expression should be given as a string. For example, batch(cl, 'y = magic(3)')
  • The name of a MATLAB function. You will usually want to prefix the name with the "at" ("@") character, and the name should not include any '.m' extension. After the function name you should pass a number indicating the number of output arguments the specified function will return. After that should come a list of the parameters to be passed to the named function, these should be given as a cell array (i.e. enclosed in curly braces '{' and '}' ). For example, if you have a function myFunction in the file myFunction.m which returns two values and you wish to evaluate it for the parameters 1, 7.2, 3.5, you could use a snippet like batch(cl, @myFunction, 2, {1, 7.2, 3.5}) or cl.batch(@myFunction, 2, {1, 7.2, 3.5}).

If needed, the above arguments can be followed by a list of name, value pairs to specify options to control even more behavior of the submitted job. When submitting jobs from your local workstation to the Cluster, the following options might be helpful:

  • 'CurrentFolder', '.'. This specifies the the directory where the MATLAB processes on the cluster will start. If omitted, it will default to the current directory for the MATLAB process from which the jobs were submitted. In the local workstation scenario, that directory is unlikely to exist on the HPC cluster and will result in a warning being produced when the job runs. Although it is only a warning and likely not to cause problems, setting the CurrentFolder to a path that exists on the HPC cluster will suppress the warning. (Setting this to '.' will cause the MATLAB process to run from the directory the ssh process ended up in, which should always exist.)
  • 'AutoAddClientPath', false. This boolean flag determines whether the user-added paths on the client MATLAB process should be added as paths to the worker MATLAB processes running on the HPC cluster. Again, in the local workstation scenario, these paths are unlikely to exist on the HPC cluster, and if they do not exist it will result in warnings being produced when the job runs. These are just warnings, and MATLAB should just ignore the non-existant paths and this should not cuase problems, but setting this parameter to false will prevent the paths from being adding effectively suppressing the warnings.

The MATLAB process on your local workstation needs to ssh into one of the login nodes of the HPC cluster. If this is the first time you needed to connect to the login node during this MATLAB session, it will prompt you for your password on the cluster. Subsequent jobs submitted from the same session will re-use the same ssh session and/or cache the password for the duration of this MATLAB session.

Combining all of these snippets, a typical sequence for submitting a job to the Zaratan HPC cluster from MATLAB running on your local workstation to run your myFunction function with the parameters as described above would be:

>> % define the cluster
>> cl = parcluster('Zaratan HPC');
>>
>> % Adjust the cluster parameters
>> cl.NumWorkers = 12;
>> cl.AdditionalProperties.WallTime = '8:00:00';
>> cl.AdditionalProperties.MemUsage = '6G';
>>
>> % Submit the job
>> job = cl.batch(@myFunction, 2, {1, 7.2, 3.5}, ...
    'CurrentFolder', '.', ...
    'AutoAddClientPath', false, ...
    );
>>
>> % Display the (MATLAB) job ID and state
>> job.ID
>> job.State

The above sequence of MATLAB commands submitted a job to the Zaratan HPC cluster to run your function myFunction with parameters 1, 7.2, 3.5. The batch function returns a job instance to the variable job, and we then print out some information about the job, namely its (MATLAB) ID number and the state of the job. The MATLAB ID number is a number used within MATLAB to identify the job; this is not the same as the Slurm job ID number, and will typically be an integer incrementing with every job you submit from MATLAB. The State parameter returns the state of the job; common values are:

  • queued: the job is in the Slurm queue, waiting to be assigned resources.
  • running: the job is running on the HPC cluster.
  • finished: the job completed

Note that MATLAB will return the job instance and allow you to continue your MATLAB session, running other MATLAB commands, and even submitting other jobs to the HPC cluster while the first job is waiting to run or running (or finished running). You could actually even disconnect from and shutdown your MATLAB session, and even turn off the system (if it is your local workstation) or log off (if you submitted the job.
The job on the HPC compute node will not be affected by such and will continue to run. Sometime later you can start up a new MATLAB session and re-load the job instance, and use that to check the status of the job and, if finished, look at the results.

To find and/or re-load job instances that we submitted in a previous MATLAB session (or from the current MATLAB session that your forgot to save to a variable or otherwise misplaced), you can use the Jobs parameter of the Cluster instance or the findJob method. The first step is to get or re-create the Cluster instance. You can just instantiate a new Cluster instance from the same Cluster Profile as you used previously. (I believe it does not even need to be the same Cluster Profile, only that the local JobStorageLocation has to be the same as was used previously.) Once you do such, you can look at all jobs that you submitted by examining the Jobs parameter of the Cluster instance. This will show all jobs you have submitted, until you explicitly delete the job from the list. The list will show the index number into the array, the Job ID, the type and state of the job, along with some other information. You can select a specific job from this array by index. This is probably the easiest way to select a job if there are only a small number of them.

Alternatively, you can use the findJob function.
The first and only required parameter to the findJob function is the Cluster instance. If that is the only parameter given, it will return the same list of jobs as the Jobs parameter of the Cluster instance. You can give additional pairs of parameters, the first in the pair being a string giving the name of a field of the Job object, and the second being a value to match against. This will filter the list of jobs so that only jobs with the specified field having the specified value pass the filter. If more than one pair of field names and values are given, each filter is applied in turn, effectively 'and'-ing the result. So you could use something like findJob(cl, 'State', 'running') to show all jobs in the running state, or findJob(cl, 'ID', 9) to return the job with ID of 9.

Once you have the MATLAB job instance (we will assume in a MATLAB variable named job, there are a number of operations you can perform:

  • job.ID will return the MATLAB ID for the job
  • job.State will return the state of the job
  • job.Tasks will return a list of tasks for the job. Of particular interest is the field SchedulerID for the task, which lists the Slurm job number associated with the task.
  • job.RunningDuration will tell you how long the job took to run
  • wait(job): As mentioned above, MATLAB will return immediately after the job is submitted, allowing you to do other things while the job is queued and/or running. If instead of doing something else and periodically checking if the job is finished, you can issue the wait(job) command, and MATLAB will not return the prompt until the job job finishes. It will not finish any more quickly, but this could be useful if you submitted a job from your local workstation and you do not want to do anything else until the job finishes. You probably should not be using this if submitting a job from MATLAB running on the cluster; if you are not planning to do anything until the job finishes and it is not a very short job, you should probably relinquish the compute node you are running on.
  • diary(job): This will report back the console output of the job, that is the text which the job normally would have written to your console had it been an interactive calculation. If the job is not outputing anything to the console (i.e. is defining a variable in a script, or setting the return value of a function), this could be empty. You should always check this for warnings or errors from running your code.
  • load(job, '*VariableName*'): if the job represented by job ran a script (as opposed to a function), the load function will transfer the variable named <var>VariableName</var> from the worker name space to the local MATLAB workspace. This only works for jobs calling a script; see fetchOutputs for jobs running a MATLAB function.
  • x = fetchOutputs(job): if the job represented by job ran a MATLAB function (as opposed to a script), the fetchOutputs function will return the return value of the evaluated function.
  • job.delete(): This will delete the job, removing all of its data from disk and causing it to no longer appear in Jobs array for the Cluster instance. You should periodically clean up the storage in the RemoteJobStorageLocation on the cluster.
  • clear job: This will delete the job variable from MATLAB

Putting the above together, if you previously submitted a MATLAB function as a job to the Zaratan cluster, where the MATLAB ID of the job was 117, and wish to check on the job's status and if finished save the the return value to a file matlab-job117.out, you could use a code snippet like:

>> jobid = 117;
>> savefile = sprintf("matlab-job%d.out", jobid);
>>
>> cl = parcluster('Zaratan HPC');
>> job = findJob(cl, 'ID', jobid);
>> if isempty(job) 
>>      % Job not found, warn user and exit
>>  error("No job with id %d found", jobid);
>> end
>>
>> if job.State == "finished"
>>  % Job not finished, warn user and exit
>>  warning("Job with id %d not finished, state=%s", jobid, job.State);
>>  exit
>> end
>>
>> % Output job state and diary
>> job.State
>> diary(job)
>>
>> % Get and save its return value
>> return_value = fetchOutputs(job);
>> save(savefile, 'return_value');
>> exit

After this snippet saves the return value of the function called in the main job, you could use the MATLAB load command to load the variables saved to matlab-job117.out for further processing.

Installing add-ons/packages/etc

The campus MATLAB license includes a fair number of licensed toolboxes. However, there are also has a large number of free and community provided toolboxes --- far too many for the Division of Information Technology to install all of them. For the most part, any individual toolkit/toolbox/package add-on is only used by at most a handful of people, so it is more efficient for the users to install these themselves.

This is relatively simple to do in the more recent MATLAB versions; from your main MATLAB screen, click on the "Add-Ons" drop down, and select "Get Add-ons". This might take a little while to open up due to the large number of add-ons available, but once open there are a number of ways to look for add-ons. If you know what add-on you want, the search bar on the top right might be the easiest way to find the add-on. Find the add-on you desire and click on it.

Once the window for the particular add-on opens, there should be a button labeled "Install" in the upper right. Click on that, and the add-on should be installed into the appropriate location in your home directory.

You will likely need an account with Mathworks/Matlab in order to download the add-ons. You can create such an account at https://www.mathworks.com/mwaccount/register; it is advised that you register with your "@umd.edu" email address to get the full benefits of your association with the University.

Additional (External) Resources

For your convenience, we provide some links to some additional resources about MATLAB which you might find useful.

We periodically sponsor workshops in conjunction with MathWorks covering parallelization techniques in general, Parallel server, and other topics we thing might be of interest to our users; please check our workshop schedule to see if there is anything scheduled in the near future.

MathWorks Documentation

These are free tutorials and other documentation from Mathworks, the company which produces MATLAB.

General Usage

Documentation and tutorials from Mathworks on general MATLAB usage, etc.:

  1. Self-paced MATLAB Onramp course ~ 2 hours
  2. MATLAB Basic Functions Reference

Parallelization in MATLAB

Documentation and tutorials from Mathworks on the general subject of parallelizing workloads in MATLAB and the Parallel Computing Toolkit:

  1. Running loops in parallel with parfor
  2. Run MATLAB functions on a GPU

MPS and HPC clusters

Documentation and tutorials from Mathworks on using MATLAB Parallel Server to submit jobs from MATLAB to an HPC cluster:

  1. MathWorks toplevel documentation on MATLAB Parallel Server
  2. Scaling up from Desktop to Cluster
  3. Running Batch Parallel Jobs
  4. Man page for batch command
  5. Detailed Job and Task Control

MathWorks also has a significant amount of web documentation on Parallel Server/MDCS

MPS and Slurm

Documentation and tutorials from Mathworks on integrating MATLAB Parallel Server (MPS) with the Slurm HPC scheduler. This is mainly for those who wish to better understand what the configCluster command is doing, and/or who wish to do some advanced customization of the Cluster Profiles:

  1. The Slurm integration scripts from Mathworks
  2. Mathworks documentation on the integration scripts
  3. Configuring MPS for a Generic Scheduler