Grid Engine Usage

This information is not being updated!

From December 2014 onwards, all the cluster related tasks moved to the IT department. Please contact Georg Rath or Petar Forrai for inquiries.

Grid Engine Overview

The Grid Engine (former Sun Gridengine) is an open source batch-queuing system typically used on a computer farm or high-performance computing (HPC) cluster and is responsible for accepting, scheduling, dispatching, and managing the remote and distributed execution of large numbers of standalone, parallel or interactive user jobs. It also manages and schedules the allocation of distributed resources such as processors, memory, disk space, and software licenses.

IMP/IMBA Overview

The cluster @IMP/IMBA is organised as a grid-like cluster (not a supercomputer cluster!). This means we have loosely coupled nodes in various hardware generations, but all configured the same on the software level. It consists of the following hardware:


nodenameamount of nodescpu(s)cores/cpucpu speedmemory/nodetotal coresnotes
compute-hp-*3243GHz16GB24Special nodes with Intel processors
bioinfo-apps5412.2GHz32GB20Old application servers e.g. albert, waibl, ...
cla*7222.6GHz8GB28Tim Clausen servers shared with the cluster


 All nodes are from Sun or HP and equipped with AMD64 CPU's except the ones mentioned above.

Additionally we have 3 nodes reserved for the Grid Engine master. Depending on the failsafe operation/takeover it should be running on one of them:


  • aragon, rainer, hutter

The current load of the cluster is monitored by the Ganglia software and can be seen on the website: aragon


Notes on Queues at IMP/IMBA

Some compute clusters have queues like highmem.q or lowpriority.q etc.. As we found out, this does not work well for the diversity of the programs used at our institutes.

Therefore we have three types of queues:

  • application specific queues for very special software requirements (e.g. ImagicXmipp, ...).
  • group specific queues where the assigned hardware suits best for the programs typically used by these groups (e.g. stark.qbioinfo.q, ...).
  • a special unlimited nonofficehours.q, which enables nearly all cluster resources for all users without any restriction during night, weekends and public holidays.