Fair use of the CÉCI clusters

Here follow the rules for using a CÉCI cluster. Those rules are meant to ensure every one a fair usage of the cluster. Click on a rule to get a detailed description.

Rule 1: The home directory is meant for code, scripts, and small data sets (and not for intensive file operations)
Rule 2: The scratch directory is meant for temporary data created/consumed by a job (and not for long-term data storage).
Rule 3: The frontend is meant for compiling, debugging, and file editing activities (and not for compute-intensive activities)
Rule 4: All computations must be submitted through the job scheduler (and not by connecting directly to the node)
Rule 5: Resources must be used as efficiently as possible (Do not request more memory, time, etc. than you actually use)
Rule 6: The private key is private (Do not share it with anyone)

Rule 1: The home directory is meant for code, scripts, and small data sets

The home directories are often designed for availability and safety, but not so much for performance. If your job makes a lot of disk access (reading and/or writing files), then it should do so in either a local scratch space or a global scratch space specifically setup for that purpose.

Rule 2: The scratch directory is meant for temporary data created/consumed by a job

The scratch directories are often designed to be able to accommodate large amounts of data very rapidly. They are meant for a job to store temporary data and should be cleaned after the job has finished. They are not meant for storing large -- or even small -- amounts of data as scratch directories are subject to arbitrary cleaning at any moment. Storing solutions are most of the time available at your university ; just contact your local sysadmin for more information.

Rule 3: The frontend is meant for compiling, debugging, and file editing activities

The frontend computer, the one to which you connect, is meant for interactive SSH sessions, file editing, compiling and debugging, and is reserved to activities which do not consume lots of cputime or memory. Any job dedicated to computing must be run on a compute node.

Rule 4: All computations must be submitted through the job scheduler

The job scheduler is designed to allocate resources fairly and efficiently. It makes sure that a job has access, at all time, to the resources it requested. It is unfair to the others, and therefore strictly forbidden, to connect to a compute node directly and run programs from there. Access to the compute node with SSH is only permitted to allow users whose jobs failed/crashed to clean the local scratch space and/or retrieve useful information about the crash (core dumps, logs, etc.) and users whose jobs are running on the node to monitor CPU and memory usage of their processes.

Rule 5: Resources must be used as efficiently as possible

Make sure that if you reserve several cores, your program is able to use them all. Do not request more than one core for a program which cannot run in parallel. Do not request cores across several nodes if your program is not designed for message passing. Do not reserve more memory, or more run time than you need (please do not leave the default values in your job scripts!). Not only specifying tight resources will leave more resources available for the others, it will first and mostly allow your job to be scheduled sooner !

Rule 6: The private key is private

The private key you use to access the CÉCI clusters is yours only and must not be shared with anyone. If you feel some of your collaborators should get access to the CÉCI clusters, please follow the correct procedure as explained in the FAQ.

© CÉCI.