Project Structure

Project

Projects the the primary unit used to manage compute and storage resources. Projects are organized in a hierarchy with a small number of top-level projects which have sub-projects, which can have their own sub-projects, and so on. The project hierarchy is to properly organize resources and properly attribute compute and storage usage to the right funding source. Each project has the following:

• Name (human readable)
• Description
• A POSIX group if the project has any users
• A Slurm account
• Some number of data store directories depending on the kind of project.
• Zero or more users, each with their own role which is used to control their permissions.
• Usually a parent project (the exception are the top-level projects)
• Zero or more sub-projects
• HPC Project ID, which is used as:
  • The name for the project’s directories in the data stores.
  • The name of the POSIX group with the prefix HPC_ (except for structural projects).
• Project path, which is the location of the project in the hierarchy represented as a POSIX path of HPC Project IDs.

Each user in a project gets their own project-specific username just for the project, which currently take the form uXXXXX where each X is a base-10 digit. If a user is a member of more than one project, they have separate project-specific usernames (and thus HOME directories, other data stores, etc.) for each but share the same SSH key that is uploaded via Academic Cloud (see the Uploading SSH Keys page).

Having a separate username for each person a project is in has the following benefits:

• Makes it easy for someone to be in projects of many different kinds (SCC, NHR, KISSKI, REACT, etc.) and even multiple of the same kind (e.g. a project and one of its sub-projects, or a course project and one’s thesis project, etc.).
• Each project-specific username has only a single Slurm account, that of the project.
  • Never need to pass -A ACCOUNT to sbatch and srun because the only account is the default one.
  • Impossible to accidentally submit Slurm jobs to the wrong account. This helps PI/s and users avoid getting very unpleasant audits from funding institutions and agencies to correct accounting problems.
• Each project-specific username gets their own HOME directory (and possibly additional directories) with their own quotas.
  • Easy to have separate configurations for each project and not have to worry about them clashing (e.g. some code has a hard coded dependency on say ~/.config/PROGRAM.cfg and you need different versions for each project).
  • Using up all of one’s quota for your HOME directory on one project doesn’t stop one’s work with another project.
  • Accidentally deleting something in the HOME or other directory of the project-specific username on one project doesn’t impact ones files with other projects.

The main downside is that one has to keep track of one’s separate project-specific usernames for each project and sharing HOME config files requires copying them (see the Data Migration Guide for how to copy and/or move data between usernames). You can log into the HPC Project Portal to see all projects that you are in and your project-specific usernames in each (see the User Perspective page for more information).

Simple Example

A simple example project hierarchy is shown in the diagram below with each project as a yellow rectangle and their users as blue stadiums. Project A is a top-level project with sub-projects B and C. Projects A and B have one user each, and project C has two users. Person Foo Bar (their Academic Cloud ID is foo.bar) is a member of Project A (project-specific username u00001) and Project C (project-specific username u00103). Person Baz Aardvark (their Academic Cloud ID is baz.ardvark) is a member of Project B (project-specific username u00003). Person Bee Clam (their Academic Cloud ID is bee.clam) is a member of Project C (project-specific username u00006).

---
title: Simple Example Project Hierarchy
---
flowchart TB

    subgraph A
        direction LR
        userA1(["u00001 (foo.bar)"])
    end

    subgraph B
        direction LR
        userB1(["u00003 (baz.aardvark)"])
    end

    subgraph C
        direction LR
        userC1(["u00006 (bee.clam)"])
        userC2(["u00103 (foo.bar)"])
    end

    A --> B
    A --> C

If the HPC Project ID of Project B is b, then the POSIX group will be HPC_b (only projects at the top of the tree may have their POSIX group be exactly their HPC Project ID without prefix). Project B would then have its Project Map located at /projects/a/b if we assume the Project A’s HPC Project ID is a. Project B might have a WORK/SCRATCH directory at /mnt/lustre-grete/projects/b. Project-specific username u00003 could have its HOME directory at /home/baz.aardvark/u00003 and a WORK/SCRATCH directory at /mnt/lustre-grete/usr/u00003.

User Roles

Each user in a project has a role that determines what they are allowed to do. The roles are:

• PI: For the project’s PI/s. Have full project management capabilities.
• Delegate: Users that the PI/s have given limited project management capabilities to, namely to manage non-PI non-Delegate users. Particularly useful for very large projects and/or busy PI/s to help the PI/s manage the users in the project.
• Member: Ordinary user with no management capabilities.

The initial role of every added user is Member. Every added user is given a project-specific username, made a member of the project’s POSIX group, and added to the project’s Slurm account. The access permissions of each role are given in the table below:

The management capabilities/permissions of each role are given in the table below:

Project Hierarchy

The exact project hierarchy at the levels above the projects each person is in is mostly an implementation detail. But in some cases it can be useful, particularly for understanding the billing and resource usage. The basic hierarchy is laid out below with the project paths and their descriptions.

• scc – Parent project of all SCC projects.
  • scc/ORGCODE – Subproject for a particular organization using the SCC. Example ORGCODE are MPG for Max-Planck-Gesellschaft, UGOE for Georg-August-Universität, UMG for Universitätsmedizin Göttingen, etc.
    • scc/UGOE/FACULTYCODE – Subproject for a faculty at Georg-August-Universität.
      • scc/UGOE/FACULTYCODE/INSTITUTECODE – Subproject for an institute at Georg-August-Universität.
        • scc/UGOE/FACULTYCODE/INSTITUTECODE/* – Subprojects for the work groups, etc. in the institute at Georg-August-Universität.
    • scc/ORGCODE/INSTITUTECODE – Subproject for an institute in the particular organization. Examples would be particular Max-Planck institutes, kliniks and institutes at Universitätsmedizin Göttingen, etc.
      • scc/ORGCODE/INSTITUTECODE/* – Subprojects for the work groups, etc. in the institute.
• extern – Parent project of all project groups external to the traditional SCC or with their own external funding.
  • extern/nhr – Parent project for all NHR projects.
    • extern/nhr/nhr_STATECODE – Parent project for all NHR projects from a particular federal state (for example, Niedersachsen is extern/nhr/nhr_ni)
      • extern/nhr/nhr_STATECODE/nhr_STATECODE_test – Project for all NHR test accounts in the particular federal state.
      • extern/nhr/nhr_STATECODE/PROJECTNAME – Individual full NHR projects in the particular federal state.
  • extern/kisski – Parent project for all KISSKI projects.
    • extern/kisski/* – Individual KISSKI projects.
  • extern/* – Parent projects for other externally funded projects.
• intern – Parent project for internal, training, etc. projects
  • intern/gwdg_training – Parent project for training courses (including the GWDG Academy).