[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] MATLAB job
> 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
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
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:
not mentioning the binary itself because it's hard-coded into
If you make a generic wrapper for your local machine, you could
run any binary as
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.
and so on.
Kevin M. Buckley Room: CO327
School of Engineering and Phone: +64 4 463 5971
Victoria University of Wellington