This is a _very_ early draft.

-----

MATLAB is an excellent match for HTCondor. Millions of MATLAB jobs, possibly tens of millions, have been successfully run under HTCondor over the years.  The specifics of working with MATLAB will vary from site to site, but here are some general guidelines.

This assumes basic familiarity with MATLAB and HTCondor. It assumes that you can set up and maintain at least a small HTCondor pool.

{section: Licensing}

Perhaps the biggest challenge to running MATLAB under HTCondor is licensing. MATLAB is proprietary software with strict licensing terms.  You might have one or two licenses for your desktop computers, but to run hundreds of simultaneous MATLAB jobs you would require hundreds of licenses.

Your institution may already have acquired suitable licensing for MATLAB.  If you have a fixed number of licenses available, HTCondor's {link:http://www.cs.wisc.edu/condor/manual/v7.6/3_13Setting_Up.html#sec:Concurrency-Limits Concurrency Limit support} can help.

Another option uses the MATLAB Compiler to create an executable that can be run with the MATLAB Compiler Runtime (MCR).  The MATLAB Compiler is an optional toolbox for MATLAB.  In general, executables created with the MATLAB Compiler are not subject to MATLAB's license; you are free to run as many in parallel as possible. _Check your MATLAB licensing to confirm this._

If you are using third party MATLAB add-ons, you will need to check the licensing on them as well.


{section: Executables}

The MATLAB executable and supporting libraries must be made available on any computers on which the HTCondor jobs might run.
When using the MATLAB Compiler, instead of the full MATLAB executable and supporting libraries, the MCR is needed.  The general techniques  for making the MCR available are the same.
Accomplish this by one of

*: *Install MATLAB on each computer that may run a MATLAB HTCondor job.*

_:If you install MATLAB locally on each computer, we recommend placing MATLAB in the _same location_ on each computer.  That way individual jobs can easily find it. Here is a portion of a user's submit description file:

{code}
executable = my_task
arguments = $$(MATLAB_PATH)
transfer_input_files= my_task.m
queue
{endcode}

_:where =my_task= would then be a script that did something like this:

{code}
#! /bin/sh
exec /opt/matlab/bin/matlab -nodisplay ./my_task.m
{endcode}

_:If MATLAB will be in _different locations_ on each computer,
use the configuration variable {link:http://www.cs.wisc.edu/condor/manual/v7.6/3_3Configuration.html#param:SubsysAttrs STARTD_ATTRS} in the local configuration file of each machine to advertise the correct location. Then, the job can use a {link:http://www.cs.wisc.edu/condor/manual/v7.6/condor_submit.html#73792 $$} expression to find the executable.  For example, the local configuration file might say:

{code}
MATLAB_PATH  = /opt/matlab/bin
STARTD_ATTRS = MATLAB_PATH
{endcode}

_:A portion of a user's submit description file:

{code}
executable = my_task
arguments = $$(MATLAB_PATH)
transfer_input_files= my_task.m
queue
{endcode}

_:where =my_task= would then be a script that did something like this:

{code}
#! /bin/sh
exec "$1"/matlab -nodisplay ./my_task.m
{endcode}

_:The batch scripts for Windows platforms are similar.

*: *Install MATLAB on a shared file system, such that it is accessible by each computer that may run a MATLAB HTCondor job.*

_:Installing on a shared file system is identical to installing it on each local computer, but may be less complicated for administration.


*: *transfer the MATLAB executable (and supporting libraries) along with the HTCondor job.*

_:To bring MATLAB along yourself, you would need to package it up, bring it along (specified with =transfer_input_files= in the submit description file), then have a script unpack MATLAB and start it.  MATLAB is a large piece of software, and this could be slow. It will also temporarily use a bunch of disk space with a copy of MATLAB.  If multiple MATLAB jobs run on the same computer simultaneously, multiple copies of MATLAB will be installed at once.  Generally speaking, this is not recommended, although it is more practical for the MCR.

{section: MATLAB Compilation}

To compile =foo.m= with the MATLAB Compiler, you would use a command like the following.  The various options are explained further below; =-R= tells MATLAB to behave as though the next option was passed in when the job is started.
{code}
mcc -m -R -singleCompThread -R -nodisplay -R -nojvm -nocache foo.m
{endcode}


{section: Invoking}

MATLAB may try to create a graphical environment.  HTCondor does not support graphical environments; it does not make sense to open up a user interface for a job that will not have a user directly looking at it.  You may need some combination of =-nosplash=, =-nodisplay=, and possibly =-nojvm= to stop MATLAB from creating a graphical environment. This should not be necessary for compiled MATLAB HTCondor jobs.

Unless you have special arrangements to use multiple CPU cores, you will want =-singleCompThread= so that MATLAB only uses a single core.

|=-nosplash=          | Disable splash screen. (No GUI support in HTCondor)|
|=-nodisplay=         | Disable GUI. (No GUI support in HTCondor)|
|=-nojvm=             | Disable GUI? Eliminate unnecessary Java (faster?)|
|=-singleCompThread=  | Only use one CPU core (play nicely when sharing computer)|



{section: Parallelism}

In the most common configuration, HTCondor does not directly support "parallel" jobs, jobs that might use a system like MPI or multiple threads to take advantage of multiple CPUs at once.  HTCondor can launch jobs that use multiple processes or threads, but by default HTCondor will offer them a single CPU core to run on.  (They may get lucky and be able to use more than one CPU core on a computer, but that should not be relied on.)

A local installation may provide additional options for parallel, usually in the form of offering a job two or more CPUs on a single computer.  Local administrators should be able to describe available functionality.

Given the default configuration, it is usually better to break your work down into multiple independent jobs.  For example, if you are processing 10,000 images, instead of a single MATLAB job that processes them, perhaps you could have 10,000 jobs that each process 1 image.  HTCondor is then able to schedule your jobs across multiple computers or at least multiple cores on a single computer, giving you the speed benefits of parallelism.

For older MATLAB (Possibly pre 2011?), to ensure that MATLAB only uses one core, put this in your MATLAB script:

{code}
lastN = maxNumCompThreads(1);   (Pre r2009bsp1)
{endcode}

If you are using the MATLAB Compiler, but want to use multiple threads when doing development, you could use something like this to limit MATLAB to one thread only for compiled versions:

{code}
if isdeployed
    lastN = maxNumCompThreads(1);
end
{endcode}

If you do the above with R2009sp1 and newer and also use the -R -singleCompThread it will error out.

*: *TODO*: Is the lastN necessary? Seems unlikely, unless MATLAB gets cranky when return values are ignored.

The above does not work on newer versions of MATLAB, as maxNumCompThreads is deprecated.  Instead, pass the =-singleCompThread= option.  If you are using mcc (the Matlab compiler), add =-R -singleCompThread= to your compiler options.

The best you can do is prevent the compiled job from using one thread per core. It will still have 5 threads with all the time on one of them. Java applications will use a few more threads. But you will have less then one thread per core which is what it will do on its own.

{section: Example}

This example assumes that MATLAB is available in =/opt/Matlab/bin=.

*COMPLETELY UNTESTED*
*:*TODO*: Is the DISPLAY=:0.0 required? Seems unlikely.
*:*TODO*: Is the HOME=. required?
*:*TODO*: Is the MATLAB_PREF=. required?

{code}
executable = /opt/Matlab/bin/matlab
arguments = -nodisplay -nojvm -singleCompThread  my-script.m
transfer_input_files = my-script.m
output = my-script.output
error = my-script.error
log = my-script.log
environment = "DISPLAY=:0.0 HOME=. MATLAB_PREF=."
queue
{endcode}

{section: Compiled MATLAB Example (completely tested)}

Given a successful mcc run, as described above, and assuming the MATLAB runtime is not pre-installed on any of the execute machines, you can transfer the runtime along with the HTCondor job.  There is an example of this in CHTC in =/home/gthain/CompiledMatlabExample=.  First, put the whole runtime into a single tar file, called =m.tgz=.  Then, edit the =run_foo.sh= wrapper (which was created by the compiler) to add the lines

{code}
tar xzf m.tgz
mkdir cache
chmod 0777 cache
export MCR_CACHE_ROOT=`pwd`/cache

{endcode}
at the beginning of the script, but after the #! line.  When MATLAB runs, it wants to create a cache directory under the user's home directory, which may not exist on an execute machine, or may conflict with other concurrently running MATLAB.  Then, create a HTCondor submit description file that looks something like:

{code}
universe = vanilla

executable = run_foo.sh
arguments = ./mathworks-R2009bSP1

should_transfer_files = yes
when_to_transfer_output = on_exit
transfer_input_files = m.tgz, foo

output = out
error  = err
log    = log
queue

{endcode}

{section: Example to run MATLAB under HTCondor on Windows}

[ copied from {link: https://lists.cs.wisc.edu/archive/htcondor-users/2013-February/msg00012.shtml this post to the htcondor-users email list} ]

I've just got this to work with Matlab R2012a 64-bit on Windows 7 64-bit
under Condor 7.6.6. This is the .bat wrapper:

{code}
set SCRIPT=%1
set MATLABEXE=c:\matlab2012\bin\win64\matlab
set MATLAB=c:\matlab2012
set TMP=%CD%
set TEMP=%CD%
set USERPROFILE=%CD%
set MATLAB_PREFDIR=%CD%\My Documents\MATLAB

mkdir "My Documents"
mkdir "My Documents\MATLAB"

set PATH=%WINDIR%\system32
set PATH=c:\matlab2012\bin\win64;%PATH%

start /wait %MATLABEXE% -noFigureWindows -nodesktop -nosplash -nojvm -r %SCRIPT%
{endcode}

When I used the -wait option it complained about a clash with the -nojvm
option. When I got rid of -nojvm it said it didn't recognise -wait although it still seemed to work. Anyway I've stuck with start /wait to be on the safe side. Pleasingly there are no error messages or warnings returned now.

Also, you may need to copy the pathdef.m file to the Condor execute folder
for the toolboxes to work (if you use them) e.g.

   copy c:\matlab2012\toolbox\local\pathdef.m .

This is useful in building standalone executables using the Matlab Compiler
Toolbox (the mcc command) actually on a pool PC.

The upshot is that the temporary Condor execute account(s) don't have a proper
profile so you need to set up an artificial one for Matlab to work (thanks
to MathWorks for pointing this out).

If you don't include a "quit" command at the end of the M-file, the
Matlab interpreter will hang around for ever waiting for the next command
and the jobs will never complete. Hindsight - always 20/20.

{section: Additional Resources}

Many other sites are using MATLAB under HTCondor.  Here are links to the documentation from just a few.

*: {link:http://www.cae.wisc.edu/matlab-condor University of Wisconsin - Madison - CAE}
*: {link:http://www.liv.ac.uk/csd/escience/condor/matlab/old_instructions.htm University of Liverpool}