Bonna Resource Sharing

Information about how computational resources on the Bonna HPC cluster are shared among users.

Group Shares & Leader Confirmations

Bonna is a small CPU-only HPC cluster (see here for more specifications and access registrations).

The total computing time available on the system amounts to about 18.6 million core-hours per year.

In accordance with the interim regulations for the use of high performance clusters at the University of Bonn, access to this time resource is shared as equally as possible (see below) among research groups.

This is also why the corresponding research group leaders are asked to decide who is entitled to consume part of their share. Put differently, if a researcher (or student) requests computational share on the Bonna system, a group leader needs to confirm that she or he is willing to supply part of his share.

In addition, the regulations generally require the access periods to be restricted. Currently, as a rule of thumb, students and fully graduated researchers receive access for six and twelve months respectively, full professors receive access for sixty months. Moreover, the access periods can be prolonged by sending a corresponding request, and accounts are deactivated when persons leave the university. See this flowchart for an illustration of the account lifecycle.

Each active group receives an equal share of the total computing time. Using these contingents, submitted jobs will be scheduled by Slurm in the following way:

  • Jobs can always be submitted irrespective of the state of the group's share. Jobs will always run as long as there are computational resources available that have not been scheduled for higher priority jobs. This means that "unused" computing time is never lost.
  • Running jobs use up the group's share according to the requested resources (CPU cores and RAM). Requesting just a single core but all of the available memory on a node is equivalent to requesting all cores.
  • When the group's share is exhausted, jobs are run with lower priority.
  • Group shares recover over time (with present settings, about 20 days of not running jobs will fully recover a share). The only consequence of continuously having an exhausted share is a lower scheduling priority.
  • When the number of research groups on the system changes, this is reflected in the size of all shares.


Wird geladen