From the point of view of LoadLeveler there are three basic classes of parallel jobs: POE jobs, PVM3.3 jobs, and other parallel jobs. Of these LoadLeveler knows best how to run POE jobs - these can be MPI, MPL, HPF, PVMe, and Linda jobs. They are all based on a concept of a static processor pool, i.e., processors are assigned to the job at the beginning of its execution, and no additionall processors can be grabbed by the job while it runs. Consequently, certain PVM concepts such as dynamic allocation and de-allocation of parallel machines are not supported. This applies also to the next class of parallel jobs that LoadLeveler knows about: PVM3.3 jobs. LoadLeveler knows how to start PVM3.3 daemons on allocated machines, and how to invoke a PVM3.3 application.
LoadLeveler has no idea how to run other parallel jobs, e.g., network-Linda jobs (the parallel Gaussian falls in this category), ISIS jobs, LAM jobs, etc. But sometimes LoadLeveler can be fooled into thinking that these are either POE or PVM3.3 jobs, and, at the very least it will produce a list of allocated nodes, which user programs or daemons can then distribute themselves over.
POE jobs are easiest to run under LoadLeveler. There is always the same
involved, regardless of whether the job is an MPI, MPL, HPF, or a Linda job. Only for PVMe jobs the executable is
#@executable=/usr/lpp/pvme/bin/pvmd3e. The only difference between, say, an MPI and an HPF
job is the compiler, that's been used to produce the POE binary.
At the very least POE jobs on the SP system should be specified by the following LoadLeveler keywords:
Adapter==hps_ip, which means ``use IP protocol over the switch''.