Running Batch COMSOL Jobs
By default COMSOL will use all available CPU cores on a computer, and on the grid some cores might be in use by other jobs. To make sure usage is balanced properly, use the parallel environment called “threaded” to request a specific number of cores. Also, COMSOL won’t run without access to your home directory (even for jobs that don’t actually access it) so we need to manually push your credentials across a queue before starting the job. (This step should last ten hours, once it’s run.)
For example, these commands will copy your credentials to the bme.q computers, then request 4 cores within a single job on that queue:
$ gridtickets bme.q |
Where inside comsoljob.sh $NSLOTS will automatically have the requested number from qsub:
#$ -cwd |
(Remember to choose either the research or educational license according to the main COMSOL instructions.) Some queues have more cores per machine available than others, and your job will only run on a computer that has the requested number of cores already free. So, while the job will run slower with fewer cores, it’ll be more likely to be able to start sooner, with one core (comsol batch -np 1) most likely to launch immediately.
Note that large amounts of data are often included beneath dotfile directories (those that start with a ‘.’) which may just be full of unneeded temporary data. For example, COMSOL stores a lot of state data in .comsol. You can speedup computations and reduce quota related crashes by moving the recovery and workspace directories. You may also want to read this for other hints.
On the Shared Computing Cluster (SCC)
Load the engineering Modules so paths work similarly to the engineering gird.
[scc2 ~]$ module use -s /ad/eng/etc/modulefiles |