since we observe a considerable amount of Matlab-Jobs in the cluster, and observe some troubles in context with the Batch-System, we have made some changes on the matlab startup-script.
Before talking about the changes we want to remind you that your scripts should be compiled using the Matlab-Compiler since we have only a few licenses in the cluster and those are meant to be used for interactive use, mainly (code-checking, profiling,...).
One major issue that repeatedly is coming up is a mismatch of ressource reservation. Matlab tries to use all hardware on a machine by default. This might be fine on your local workstation but it's not on a cluster. As for Matlab there's just the option of taking one core or taking them all. This can be controlled by the use of the flag -singleCompThread. It seems like not many users are aware of this, which made us changing the startup to use this flag -singleCompThread by default. If you have a script that takes advantage of internal, parallelized routines of Matlab and want to allow it to take the full machine, you have to use the new flag -multiCompThread and reserve a full node, of coure.
Let's look at two examples how to start Matlab, just to elaborate it:
1.) Matlab-Script that needs only one computational thread
matlab -nosplash -r my_singleComp_script
2.) Matlab-Script that makes use of a lot of internal, parallelized routines (only inside an interactive job):
matlab -nosplash -multiCompThread -r my_multiComp_script
As mentioned above, the code should be compiled when run in the cluster as a job. Accordingly, the compiling should look like:
1.) mcc -R -m my_singleComp_script
2.) mcc -R -multiCompThread -m my_multiComp_script
Note that it's NOT '-R -multiCompThread' but just '-multiCompThread'.
Your job reservation has to be adapted to the needs of your script, of course.
We have added the environment variable MATLABROOT to the module files to make the call of your compiled code a little more convenient:
./run_myCompiledCode.sh $MATLABROOT arg1 arg2 arg3 ...
In case you have a strong use of the Floating-Point-Unit you might consider using -R 'affinity[core(2)]' or more advanced reservations.