eMinerals people Member sites eMinerals science Documents Site map

Environment from the Molecular Level

A NERC eScience testbed project

Portable Batch System

The Portable Batch System, PBS, is a batch job and computer system resource management package. It will accept batch jobs ( shell scripts with control attributes), preserve and protect the job until it is run, run the job, and deliver output back to the submitter.

PBS may be installed and configured to support jobs run on a single system, or many systems grouped together. Because of the flexibility of PBS, the systems may be grouped in many fashions.

PBS consist of four major components: commands, the job Server, the job executor, and the job Scheduler. A brief description of each is given here.

Commands

PBS supplies both command line commands and a graphical interface. These are used to submit, monitor, modify, and delete jobs. The commands can be installed on any system type supported by PBS and do not require the local presence of any of the other components of PBS. There are three classifications of commands:

Operator and administrator commands require different access privileges.

Job Server

The Job Server is the central focus for PBS. Within this document, it is generally referred to as the Server or by the execution name pbs_server. All commands and the other daemons communicate with the Server via an IP network. The Server's main function is to provide the basic batch services such as receiving/creating a batch job, modifying the job, protecting the job against system crashes, and running the job (placing it into execution). One server manages one or more queues; a batch queue consists of a collection of zero or more batch jobs and a set of queue attributes. Jobs are said to reside in the queue or be members of the queue. In spite of the name, jobs residing in a queue need not be ordered first in, first out. Access to a queue is limited to the server which owns the queue. All clients gain information about a queue or jobs within a queue through batch requests to the server. Two main types of queues are defined: routing queues and execution queues. When a job resides in an execution queue, it is a candidate for execution. A job in execution is still a member of the execution queue from which it was selected for execution. When a job resides in a routing queue, it is a candidate for routing to a new destination. Each routing queue has a list of destinations to which jobs may be routed. The new destination may be a different queue within the same server or a queue under a different server. The Job Server must know the list of nodes that can execute jobs: they are declared in a file in the server private directory PBS_HOME/server_priv.

Job Executor

The job executor is the daemon which actually places the job into execution. This daemon, pbs_mom, is informally called Mom as it is the mother of all executing jobs. Mom places a job into execution when it receives a copy of the job from a Server. Mom creates a new session as identical to a user login session as is possible. For example, if the user's login shell is csh, then Mom creates a session in which .login is run as well as .cshrc. Mom also has the responsibility for returning the job's output to the user when directed to do so by the Server. There must be a Mom running on every node that can execute jobs.

Job Scheduler

The Job Scheduler is another daemon which contains the site's policy controlling which job is run and where and when it is run. Because each site has its own ideas about what is a good or effective policy, PBS allows each site to create its own Scheduler. When run, the Scheduler can communicate with the various Moms to learn about the state of system resources and with the Server to learn about the availability of jobs to execute. The interface to the Server is through the same API as the commands. In fact, the Scheduler just appears as a batch Manager to the Server.

In addition to the above major pieces, PBS also provides an Application Program Interface, API, which is used by the commands to communicate with the Server. This API is described in the section 3 man pages furnished with PBS. A site may make use of the API to implement new commands if so desired.

General references

Papers that describe the eMinerals science areas are:

  1. Environment from the molecular level: an escience testbed project.
    MT Dove, M Calleja, J Wakelin, K Trachenko, G Ferlat, P Murray-Rust, NH de Leeuw, Z Du, GD Price, PB Wilson, JP Brodholt, M Alfredsson, A Marmier, RP Tyer, LJ Blanshard, RJ Allan, K Kleese van Dam, IT Todorov, W Smith, VN Alexandrov, GJ Lewis, A Thandavan, SM Hasan.
    Proceedings of UK e-Science All Hands Meeting 2003, (EPSRC, ISBN 1-904425-11-9) pp 302–305

  2. Grid computing and molecular simulations: the vision of the eMinerals project.
    MT Dove and NH de Leeuw.
    Molecular Simulations 31, 297–301, 2005

  3. Collaborative grid infrastructure for molecular simulations: The eMinerals minigrid as a prototype integrated compute and data grid.
    M Calleja, R Bruin, MG Tucker, MT Dove, RP Tyer, LJ Blanshard, K Kleese van Dam, RJ Allan, C Chapman, W Emmerich, PB Wilson, JP Brodholt, A Thandavan, VN Alexandrov.
    Molecular Simulations 31, 303–313, 2005

  4. eMinerals: Science Outcomes enabled by new Grid Tools.
    M Alfredsson, E Artacho, M Blanchard, JP Brodholt, CRA Catlow, DJ Cooke, MT Dove, Z Du, NH de Leeuw, A Marmier, SC Parker, GD Price, JMA Pruneda, W Smith, I Todorov, K Trachenko, and K Wright.
    Proceedings of All Hands 2005 (ISBN 1-904425-53-4), pp 788–795, 2005