Re: [Condor-users] MATLAB job

[Kevin.Buckley@xxxxxxxxxxxxx]

> Some of the information is specific to MU, but most of it should
> generalize to other Condor pools that have the matlab runtime
> environment installed on the execute nodes.

This is more MCR- than Condor- specific but might be useful:

one thing to consider for MCR jobs is that when you compile your M-code
you'll usually get both the binary execuatble and a wrapper script that
allows you to run that binary anywhere, as long as you specify the path
to the local MCR (the wrapper also set a few environmental variables
and paths).

It is possible to take the wrapper and make it generic for machines
in your pool.

What this allows is for the bloke submitting the job to merely send
the binary to the execution nodes and run against a known wrapper,
rather than having to work out how to pass the remote machine's MCR
location to the wrapper, ie, leaving it up to the remote machine to
do the setup work.

(Slightly different in the windows world where merely having the
  path to the MCR directory on your %PATH%, when you invoke the
  binary, is enough)

Say you start with your matlab commands in

 test1.m

You compile to give yourself (I think these are the default names)

 runtest1     (the binary)
 runtest1.sh  (the wrapper with the binary name hard-coded)

which you'ld then distribute and/or run anywhere as:

 runtest1.sh /some/path/to/the/local/MCR

not mentioning the binary itself because it's hard-coded into
the wrapper.

If you make a generic wrapper for your local machine, you could
run any binary as

  run_mcr.sh /some/path/to/any/binary

Where I've found this useful was in environments where the user
was not submitting direct to a local grid but was coming in through
an external queuing infrastructure (Globus) - all the user needs
to stage in is the binary and any support/data files: the generic
wrapper on the server-side taking care of the MCR side of things.

As David's slides note, mismatch of Matlab versions can be an issue,
so again, the ability to have as many version-specific generic wrappers
(what a tautology!) as you have MCR installtions can also be useful, eg.

 run_mcr2010b.sh
 run_mcr2011a.sh

and so on.



Kevin

-- 
Kevin M. Buckley                                  Room:  CO327
School of Engineering and                         Phone: +64 4 463 5971
 Computer Science
Victoria University of Wellington
New Zealand