Matlab is a numerical computing and programming environment with a broad range of functionality (matrix manipulation, numerical linear algebra, general-purpose graphics, etc.). Additionally, special application areas are served by a large number of optional toolboxes.
Running Matlab on the headnode
Users need to avoid using the head node for processing using Matlab or other software. However, Matlab Distributed Computing toolbox/server is installed on the cluster and this requires running Matlab on the head node due to how it integrates with SLURM.
How do I run Matlab graphically on the cluster?
X Window System (X11) server will be needed on your local computer. How you get this will depend on your local computer’s operating system and your preferences. This is covered in more detail in the article Logging onto the Cluster.
Users who want to use Matlab graphically and display it on their local computers will need to schedule an interactive session in SLURM using a similar command to this. In is important to include –x11 and adjust the request to the necessary resources (queue, # cpus, memory and time ) you will need for your interactive session.
srun --x11 -p cpu --cpus-per-task=1 --mem=10GB --time=4:00:00 --pty $SHELL
The following is the command set and output from the above screen capture:
dpane@my-vm:~$ ssh -Y dpane@mind.cs.cmu.edu dpane@mind.cs.cmu.edu's password: Last login: Thu Feb 13 07:38:02 2020 from claymore.cnbc.cmu.edu . . [dpane@mind ~]$ [dpane@mind ~]$ srun --x11 -p cpu --cpus-per-task=1 --mem=10GB --time=4:00:00 --pty $SHELL [dpane@mind-1-21-1 ~]$ module load matlab-9.5 [dpane@mind-1-21-1 ~]$ matlab MATLAB is selecting SOFTWARE OPENGL rendering. Gtk-Message: 13:05:49.875: Failed to load module "canberra-gtk-module" exit [dpane@mind-1-21-1 ~]$ exit exit srun: error: mind-1-21-1: task 0: Exited with exit code 1 [dpane@mind ~]$
If you receive “srun: error: No DISPLAY variable set, cannot setup x11 forwarding.” error, try logging onto the cluster using the X11 option
[dpane@mind ~]$ srun –x11 -p cpu –cpus-per-task=1 –mem=10GB –time=4:00:00 –pty $SHELL
srun: error: No DISPLAY variable set, cannot setup x11 forwarding.
You should try using on of the following options when you remote login program using ssh.
-Y ==> Enables trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls.
Non-interactive Matlab Sessions
Using Matlab in the interactive mode, as we explain above, can be used to take advantage of the integrated environment. However, it can also be run in a non-interactive way that is suitable for “batch processing” and will allow users to takefull advantage of cluster resources. In most cases, the preferred mode of operation for Matlab on our cluster is non-interactive.
One way to run Matlab non-interactively is through
- re-directing the standard input and output when invoking Matlab and
- invoking Matlab from a submission script, submitted to the queue via the PBS scheduler.
Input and output re-direction is an one way of running Matlab non-interactivelly. It is achieved using the Linux operators < and > , with Matlab taking a code file as an input and writing the output to a file, e.g. matlab < myScript.m > myOutput.txt . The main function/program (e.g. myScript.m) should have the exit command at the end in order to force Matlab to quit after finishing the execution of the code.
Here is an example demonstrating a non-interactive Matlab program. A program file named mystats.m that contains a main function, mystats, and two local functions, mymean and mymedian.
function [avg, med] = mystats(x)
n = length(x);
avg = mymean(x,n);
med = mymedian(x,n);
end
function a = mymean(v,n)
% MYMEAN Example of a local function.
a = sum(v)/n;
end
function m = mymedian(v,n)
% MYMEDIAN Another example of a local function.
w = sort(v);
if rem(n,2) == 1
m = w((n + 1)/2);
else
m = (w(n/2) + w(n/2 + 1))/2;
end
end
The job is sent to the queue and executed on a backend node using the following PBS file provided and the command qsub run.sh. The script run.sh contains the following line to run the Matlab script:
matlab -nodisplay -nosplash < mystats.m > run.log
The flag nodisplay instructs Matlab to run without the GUI, while nosplash prevents the display of the Matlab logo. The < redirection operator ensures that Matlab runs the script main.m, while the > operator re-directs the standard output (normally to the terminal) to run.log file.
The example is run in batch mode with the command sbatch run.sh, using the following PBS file:
#!/bin/bash -l # Job name #SBATCH --job-name=batch_matlab_example # Run on a single CPU #SBATCH --ntasks=1 # Submit job to cpu queue #SBATCH -p cpu # Job memory request #SBATCH --mem=10gb # Time limit days-hrs:min:sec #SBATCH --time 00-00:05:00 # Standard output and error log #SBATCH --output=/user_data/dpane/exampleOut.out hostname echo "job starting" module load matlab-8.6 cd /old_home/dpane/from_Brian/klab_Suite2P_SLURM_201906 echo "RUNNING MATLAB" matlab -nodisplay -nosplash < main.m > run.log module unload matlab-8.6 echo "job finished"
Notice how MATLAB is instructed to not load the interactive window.
Note: do not turn java off when lauching MATLAB (i.e. do not invoke matlab -nojvm); matlabpool uses the Java Virtual Machine.
After the job finishes, the CPU times spent executed the loops in main.m can be found in timings.dat, showing a clear speed-up of the execution in parallel.
Running Matlab on parallel hardware
Matlab can also be run where you can take advantage of parallel hardware. You should refer to the Matlab documentation for details on learning how to take advantage of these features.
Exploiting trivial parallelism
An easy way to exploit multi-core systems is to split the workflow into parts that can be processed completely independently. The typical example in this category is a parameter sweep, where the same Matlab script is run a large number of times using different inputs; these runs are independent from each other and can be carried out concurrently. Thus, the entire workflow can be scheduled in jobs that group 8 independent runs to match the 8 cores available per compute node. This strategy is best coupled with the use of the Matlab mcc compiler in order to avoid an excessive use of licenses.
Multi-threaded MEX programming
Yet another way to exploit multi-core systems is via multi-threaded Mex programming. Mex (Matlab EXecutable) files are dynamically linked subroutines compiled from C, C++ or Fortran source code that can be run from within Matlab in the same way as M-files or built-in functions. These guidelines assume knowledge of serial Mex programming and provide an example of how to augment serial execution with multi-threading through OpenMP. Coupled with OpenMP multi-threading, Mex files become a powerful method to accelerate key parts of a Matlab program.
The main reason to write Mex files in C or Fortran (thus abandoning the high-level abstracted Matlab programming) is to gain speed of execution in computationally intensive operations that otherwise become a bottleneck in an application. Typically, this is done to replace a function that is identified through profiling as being slow and/or called a large number of times. Nevertheless, this programming effort is rewarded to various degrees, with the greatest relative benefits normally met when a Mex replaces a Matlab script (M-file). At the other extreme, Matlab operations that rely on performance libraries like FFTW (e.g. fftn) or BLAS/LAPACK (e.g. solution of a dense linear systems, A\b), which are highly optimised have nothing or very little to benefit from Mex programming. The best source for learning Mex programming is the Mathworks webpages.