rsnt_translations
57,772
edits
MATLAB: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 34: | Line 34: | ||
<!--T:39--> | <!--T:39--> | ||
If you get the message ''This version is newer than the version of the license.dat file and/or network license manager on the | If you get the message ''This version is newer than the version of the license.dat file and/or network license manager on the server machine'', try an older version of MATLAB in the <code>module load</code> line. | ||
server machine'', try an older version of MATLAB in the <code>module load</code> line. | |||
<!--T:40--> | <!--T:40--> | ||
| Line 148: | Line 147: | ||
= Running multiple parallel MATLAB jobs simultaneously = <!--T:33--> | = Running multiple parallel MATLAB jobs simultaneously = <!--T:33--> | ||
There is a known issue when two (or more) parallel MATLAB jobs are initializing their <code>parpool</code> simultaneously : multiple new MATLAB instances are trying to read and write to the same <code>.dat</code> file in the <code>$HOME/.matlab/local_cluster_jobs/R*</code> folder, which corrupts the local parallel profile used by other MATLAB jobs. To fix the corrupted profile, delete the <code>local_cluster_jobs</code> folder when no job is running. | There is a known issue when two (or more) parallel MATLAB jobs are initializing their <code>parpool</code> simultaneously: multiple new MATLAB instances are trying to read and write to the same <code>.dat</code> file in the <code>$HOME/.matlab/local_cluster_jobs/R*</code> folder, which corrupts the local parallel profile used by other MATLAB jobs. To fix the corrupted profile, delete the <code>local_cluster_jobs</code> folder when no job is running. | ||
<!--T:34--> | <!--T:34--> | ||
| Line 157: | Line 156: | ||
#* using always increasing delays (which are wasting compute time), | #* using always increasing delays (which are wasting compute time), | ||
#* using Slurm options <code>--begin</code> or <code>--dependency=after:JOBID</code> to control the start time (which increases wait time in the queue). | #* using Slurm options <code>--begin</code> or <code>--dependency=after:JOBID</code> to control the start time (which increases wait time in the queue). | ||
# Making sure each MATLAB job | # Making sure each MATLAB job creates a local parallel profile in a unique location of the filesystem. | ||
<!--T:35--> | <!--T:35--> | ||
| Line 179: | Line 178: | ||
<!--T:38--> | <!--T:38--> | ||
References: | References: | ||
* FAS Research Computing, [https://www.rc.fas.harvard.edu/resources/documentation/software/matlab-pct-simultaneous-job-problem/ MATLAB Parallel Computing Toolbox simultaneous job problem] | |||
* MathWorks, [https://www.mathworks.com/matlabcentral/answers/97141-why-am-i-unable-to-start-a-local-matlabpool-from-multiple-matlab-sessions-that-use-a-shared-preferen ... from multiple MATLAB sessions that use a shared preference directory] | |||
= Using the Compiler and Runtime libraries = <!--T:26--> | = Using the Compiler and Runtime libraries = <!--T:26--> | ||
| Line 195: | Line 194: | ||
<!--T:10--> | <!--T:10--> | ||
This will produce a binary named <tt>cosplot</tt>, as well as a wrapper script. To run the binary on Compute Canada servers, you will only require the binary. The wrapper script | This will produce a binary named <tt>cosplot</tt>, as well as a wrapper script. To run the binary on Compute Canada servers, you will only require the binary. The wrapper script named <tt>run_cosplot.sh</tt> will not work as is on our servers because MATLAB assumes that some libraries can be found in specific locations. Instead, we provide a different wrapper script called <tt>run_mcr_binary.sh</tt> which sets the correct paths. | ||
<!--T:18--> | <!--T:18--> | ||