| Home | My Accounts | Newsletter | News Flash | Contact Us | Search |
|
  |
by Brian Hopkins One common reason that jobs fail to run in parallel is that the application is not made aware that there are multiple processors available to it. Simply requesting multiple processors in a PBS script (including standard scripts like g03sub) will not cause an application like Gaussian to run in parallel. To do so, special commands are needed in the Gaussian input file. Redwood and Sweetgum are shared memory supercomputers. To to run Gaussian in parallel on these systems, simply add the line %nprocs=ncpus (where ncpus is the number of processors you'd like to use) to the beginning of your Gaussian input file. Then submit the job via PBS, making sure to request the same number of CPUs. The job should then run in parallel. Unlike the two SGI machines, the Mimosa cluster is a distributed memory system. To run Gaussian in parallel on such a system, add the line %nprocl=nodes (where nodes is the number of nodes you'd like to use) to the beginning of a Gaussian input file. Then submit the job via PBS, making sure to request the same number of nodes. The job should then run in parallel. It's important to emphasize that the %nprocs and %nprocl commands are not equivalent. Use of %nprocl on Sweetgum or Redwood will not cause Gaussian to crash, but it will not casue Gaussian to run in parallel, either. It is therefore improtant to take special care when porting input files from Mimosa (where %nprocl is needed) to Sweetgum or Redwood (where %nprocs is needed). Jobs submitted without the correct %nproc command will run on only one processor, regardless of how many processors PBS reserves for the job. Any other processors set aside by PBS will sit idle until the job finishes. |
