Metropolis uses the SLURM (Simple Linux Utility for Resource Management System) batch job system. SLURM handles both serial and parallel jobs and it is responsible for allocating the required resources (CPU and Memory) for each job. Nodes at Metropolis are organized into virtual node groups called partitions. Each partition contains nodes with similar resources and jobs running in each partition share the same characteristics in terms of cpu, maximum allowed memory allocation, total cpu time and so on. The purpose of each partition and its characteristics are explained in the following table^*:

All jobs should be submitted and handled by the SLURM scheduler, otherwise they are discarded. Please, bare in mind that this is a multi user system. Resources are shared between users and groups and there is not such thing as "unlimited resources. That said, please read the following "code of ethics" (courtesy of Dr. Jacek Herbrych):

• Think twice before starting very heavy calculations. Are the parameters correct? Is the calculation necessary at all?
• Don't interfere with other users' work. Badly behaved programs will be terminated.
• If you generate huge amounts of data, exclude them from backup. Try to keep your daily backup below 1 GB.
• Try not to allocate more than 4 GB of RAM per thread. Currently only CPU usage counts in the fair share system, however this may change in the future since the number of cores per CPU grows faster than RAM sizes on typical computers.
• Run parallel code whenever possible. OpenMP and MPI stacks are provided.
• Try to keep your jobs short, ideally a few days at most. Parallelize your code to achieve that, or use checkpointing (your own or use a library like Berkeley checkpointing). The longer your job, the less likely it is to properly finish. Furthermore, there are other mechanisms of job failure, such as hard ECC errors, malfunctioning programs of other users, etc.

Resource allocation and job scirpts examples

More complex batch scripts examples