Best:Using gimel: Difference between revisions

From DISI
Jump to navigation Jump to search
(asdf)
(asdf)
 
Line 1: Line 1:
When using our cluster, please be respectful of other users.
If you use one of our standard protocols, such as 3D building or docking, then it is very likely you are already using best practices. If you have written a new workload, or substantially modified an existing one, please check that you are using best practices to avoid interfering with others' work.
== Checklist ==
* do you write to /tmp?  Please use /scratch/<userid> instead.
* do you clean up data written to /scratch during your job?
* for a new program, do you use srun to test the job before submitting using batch?  See below
== Best practices ==
* with a new workload, after you have tested with srun, try to scale by by logs.  Thus, try with 1M (or whatever) molecules first, before trying 10M, 100M, 1B, and so on.  The small scale will be quick, and your lab mates will thank you.
* for a new workload, you can check in with a member of jjiteam or [[sysadmins]] to verify that your new workload does not use too much memory, or is properly assigned to machines that can handle it.
* there are similar best practices for wynton, which we will write.
== Using srun to test a job before submitting to sbatch ==
Here is how you do it.




[[Category:Best]]
[[Category:Best]]

Latest revision as of 20:31, 4 March 2025

When using our cluster, please be respectful of other users. If you use one of our standard protocols, such as 3D building or docking, then it is very likely you are already using best practices. If you have written a new workload, or substantially modified an existing one, please check that you are using best practices to avoid interfering with others' work.

Checklist

  • do you write to /tmp? Please use /scratch/<userid> instead.
  • do you clean up data written to /scratch during your job?
  • for a new program, do you use srun to test the job before submitting using batch? See below

Best practices

  • with a new workload, after you have tested with srun, try to scale by by logs. Thus, try with 1M (or whatever) molecules first, before trying 10M, 100M, 1B, and so on. The small scale will be quick, and your lab mates will thank you.
  • for a new workload, you can check in with a member of jjiteam or sysadmins to verify that your new workload does not use too much memory, or is properly assigned to machines that can handle it.
  • there are similar best practices for wynton, which we will write.


Using srun to test a job before submitting to sbatch

Here is how you do it.