Conduct & Best Practice

  • Be kind to other users, don’t run too many jobs at once or fill up the scratch drive.
  • Don’t run jobs on the login node, submit them to the cluster with Slurm instead.
  • Don’t run serial jobs in the compute partition on Hawk, use the HTC partition instead. Sunbird has no HTC partition and its compute partition is for both serial and parallel jobs.
  • Only run jobs which need a GPU on the GPU partition.
  • Use the test partition for testing short runs of your software.
  • If you are a member of multiple projects, use the -A option to sbatch to ensure your job is accounted against the right project.
  • Try to match your job specification to its actual needs. Don’t request more memory, CPU cores or time than you need.
  • If you request exclusive use of a node, make sure you are using all 40 cores. We have relatively few nodes, each with a lot of cores.
  • Make sure that jobs last at least a few minutes. Small jobs add a lot of overhead to the scheduler.
  • Use GNU Parallel to combine multiple small jobs into a single larger one.
  • Don’t store data on scratch, it may be deleted after 60 days of non-access.
  • Don’t use SCW as a long term data store, home directories aren’t backed up. If you need a long term data store ask your institution.
  • Publish your data and somebody else will store it for you!
    • Data sets up to 50 gigabytes can be published via Zenodo.
    • Data, code and protocols can be submitted for peer review and publication via GigaScience.
  • Credit SCW in your publications.
  • Tell SCW staff if you get a paper published from work which used the system or if you get a grant that will use it funded.