The Lichtenberg HPC can only be used via projects, defining the approved amount of resources the project can allocate on the HPC. In other words, a project's allotted number of core*hours determines the “share” of the overall computing resources of the HPC for this project.

All core*hours used within the course of a project are accounted on that project (like money spent is accounted on a bank account).

A user account (personalized) is associated with one or more projects (the first project being that user's default project).
Unlike this strictly personalized user account, projects can and are permitted to be shared among several colleagues and students working on the same scientific problem.

As projects can have several users/members, and a given user can be member of several projects, the validity terms of HPC user accounts and HPC projects are completely independent of each other. Both can expire (run out) at different dates, and extending one does not imply extending the other.

For projects having several TU-IDs assigned, a shared project directory in /work/projects can be set up, initially having 5 TByte of quota.

As this is not done by default at activation of approved projects, please contact us, mentioning the project ID in the subject of your mail.

_{At creation time of a project directory, all current project members have access to it. If the PoC later adds further members to his/her project, their access will not be granted until the next day (all access updating only runs nightly).}

Submitting batch jobs is not possible without (implicitly) specifying a project (sbatch -A parameter). If a user does not explicitly specify sbatch -A <projectname>, the job will be allocated on that user's default project.

The Lichtenberg cluster used to run in “user-exclusive” mode: a given compute node would always execute only jobs of the same user at the same time.

For a better overall utilization of the resources and shorter “pending” times, this has been switched off: any given compute node can now execute several different users' jobs concurrently, if these are small enough to share a node.

For small jobs with no overly large memory footprint, we still recommend to request even dividers of the amount of cores per node, so as to have these jobs share a given compute node without “clipping” waste of resources. In our case of compute nodes with 96 cores:

For this to work, strictly avoid the

#SBATCH --exclusive

pragma, as this would assign every (small) job its own, separate compute node! This would only be useful for real benchmarking, ie. precisely assessing the performance of the node(s).

Resources used

With the commands csum and csreport, any user can get a list of their current overall resource consumption.

Monthly Usage Report

At the end of a month, users get an automatic email with a usage overview on all projects they are associated with (“Lichtenberg User Report”).

Due to changes in the cluster's job accounting, the former graphs of your projects' usage and job efficiency are currently unavailable.