Running Calculations - Revision history

A Flachmueller at 15:55, 23 October 2026

2026-10-23T15:55:37Z

← Older revision		Revision as of 17:55, 23 October 2026
Line 75:		Line 75:

	→ '''[[Job Monitoring]]'''		→ '''[[Job Monitoring]]'''

	== Dos and Don'ts ==

	There are a number of pitfalls users might encounter when starting to use compute clusters. To avoid some of them, we've collected some best practices in the form of a Dos and Dont's list. It is meant to serve as guidance, not as an absolute imperative, because sometimes stricly avoiding every undesired behaviour is not feasible, though discussing those cases with the cluster operators beforehand is a good idea.

	{\| style="background:#deffee; width:100%; font-size:100%;"
	\|'''Dos:'''
	* Bundle large amounts of tiny calculations (e.g. 1000 short running analyses taking 2 minutes each) together into fewer / a single job(s) that orchestrates them to run consecutively (and maybe even distributes them among different cores)
	* Estimate the total calculation time of your job. A short test run (either on your local machine or on the cluster) can help, though transferability and extrapolation lead to inaccuracies.
	:: → Request a calculation time larger than your estimate. For a new calculation about 20%-30% more time than estimated often is a feasable starting point. Good time estimates are below 10% of extra time requested.
	:: → Having the requested time be close to the actual calculation time is beneficial for the cluster because it helps the scheduler to be more precise and thus shortens idle times.
	* Plan early what calculations you want to perform and create a rough timetable for when you want to submit them. Keep cluster waiting times in mind and ideally have some buffer before important deadlines (e.g. paper submission deadlines).
	:: → The scheduler does not know of your urgency and you have no way of communicating your urgency to the scheduler. Therefore the bwHPC recommends to avoid generating the need for urgent calculations. We however also know that sometimes urgency can not be avoided. In such cases contact the cluster operators to see if they can help you out. Don't ask for this lightly, because if everything is urgent, nothing is!
	:: → Many things have a tendency to avoid obliging to plans. Sudden problems can arise both on the user end and on the cluster end, so having a personal time buffer for such cases is good for anxiety prevention.
	* Be mindful when performing very long calculations. For a multitude of reasons a computation job may suddenly end during the run. The longer the calculation the higher the risk of an unexpected error.
	:: → If possible create checkpoint files regularly during your calculations, from which you can pick up the calculation again.
	* Keep communication bottlenecks in mind when requesting resources.
	:: → With greater physical distance between compute units (cores) comes a longer communication time between them. This leads to efficiency losses depending on the communication volume and frequency.
	\|}
	<br>
	{\| style="background:#FFCCCC; width:100%; font-size:100%;"
	\|'''Don'ts:'''<br>
	* Do not run very short jobs (single digit minutes) on regular compute nodes. Some clusters offer separate partitions for short running jobs.
	:: → For the sake of efficiency small calculations should use few cores and accept runtimes larger than 1 hour.
	:: → If a parallelizable compute job calculates in under 1 hour on 1 core you should check your reasoning why it needs to run on the cluster at all instead of your local machine. Most (if not all) modern consumer machines do have multiple cores available and often have higher clock speeds than cluster CPUs. The true power of modern compute clusters comes from splitting large parallelizable calculations over many compute cores, usually at the cost of somewhat lower core clock speeds.
	* Do not unnecessarily split your calculation into many tiny short running jobs to "trick" the backfilling system by using every 5 minute idle gap that may occur.
	:: → Allocation of a job onto the compute nodes takes up some time for every job, as does cleanup afterwards. Thus by splitting a calculation its overall efficiency decreases accordingly.
	:: → The scheduler assigns and updates priorities and starting times of jobs frequently. A higher number of jobs in the queue means a higher workload for the scheduler, leading to unnecessary strain of the system.
	* Do not request resources that remain unused by your job.
	:: → The Resource Management System calculates your recent usage by multiplying the number of requested compute resources (CPU cores / GPUs) by the time the job was allocated. So if 90% of the cores are idle most of the time or not used at all doesn't matter to the system, it will always use 100% of the requested compute resources for the calculation of the Fair Share Value. For the time it however uses the actual allocated time of the jobs instead of what was requested.
	:: → Requesting lots of compute resources for a job usually leads to longer waiting times in the queue compared to less resource intensive jobs.
	* Do not spawn too many threads with your jobs. Although multithreading allows some code to run overall more efficient due to better resource usage, spawning too many threads on a compute unit has the contrary effect because the threads have to be managed.
	:: → Be mindful when increasing the thread count and analyse your actual performance gain.
	\|}

A Flachmueller: /* Dos and Don'ts */

2026-10-19T09:48:10Z

Dos and Don'ts

← Older revision		Revision as of 11:48, 19 October 2026
Line 104:		Line 104:
	:: → The scheduler assigns and updates priorities and starting times of jobs frequently. A higher number of jobs in the queue means a higher workload for the scheduler, leading to unnecessary strain of the system.		:: → The scheduler assigns and updates priorities and starting times of jobs frequently. A higher number of jobs in the queue means a higher workload for the scheduler, leading to unnecessary strain of the system.
	* Do not request resources that remain unused by your job.		* Do not request resources that remain unused by your job.
	:: → The Resource Management System calculates your recent usage by multiplying the number of requested compute resources (CPU cores / GPUs) by the time the job was allocated. So if 90% of the cores are idle most of the time or not used at all doesn't matter to the system, it will always use 100% of the requested compute resources for the calculation of the Fair Share Value. For the time it however uses the actual ~~walltime~~ of the jobs.		:: → The Resource Management System calculates your recent usage by multiplying the number of requested compute resources (CPU cores / GPUs) by the time the job was allocated. So if 90% of the cores are idle most of the time or not used at all doesn't matter to the system, it will always use 100% of the requested compute resources for the calculation of the Fair Share Value. For the time it however uses the actual allocated time of the jobs instead of what was requested.
	:: → Requesting lots of compute resources for a job usually leads to longer waiting times in the queue compared to less resource intensive jobs.		:: → Requesting lots of compute resources for a job usually leads to longer waiting times in the queue compared to less resource intensive jobs.
	* Do not spawn too many threads with your jobs. Although multithreading allows some code to run overall more efficient due to better resource usage, spawning too many threads on a compute unit has the contrary effect because the threads have to be managed.		* Do not spawn too many threads with your jobs. Although multithreading allows some code to run overall more efficient due to better resource usage, spawning too many threads on a compute unit has the contrary effect because the threads have to be managed.

A Flachmueller: /* Dos and Don'ts */

2026-10-16T12:37:49Z

Dos and Don'ts

← Older revision		Revision as of 14:37, 16 October 2026
Line 91:		Line 91:
	* Be mindful when performing very long calculations. For a multitude of reasons a computation job may suddenly end during the run. The longer the calculation the higher the risk of an unexpected error.		* Be mindful when performing very long calculations. For a multitude of reasons a computation job may suddenly end during the run. The longer the calculation the higher the risk of an unexpected error.
	:: → If possible create checkpoint files regularly during your calculations, from which you can pick up the calculation again.		:: → If possible create checkpoint files regularly during your calculations, from which you can pick up the calculation again.
			* Keep communication bottlenecks in mind when requesting resources.
			:: → With greater physical distance between compute units (cores) comes a longer communication time between them. This leads to efficiency losses depending on the communication volume and frequency.
	\|}		\|}
	<br>		<br>

A Flachmueller: /* Dos and Don'ts */

2026-10-16T08:39:06Z

Dos and Don'ts

← Older revision		Revision as of 10:39, 16 October 2026
Line 89:		Line 89:
	:: → The scheduler does not know of your urgency and you have no way of communicating your urgency to the scheduler. Therefore the bwHPC recommends to avoid generating the need for urgent calculations. We however also know that sometimes urgency can not be avoided. In such cases contact the cluster operators to see if they can help you out. Don't ask for this lightly, because if everything is urgent, nothing is!		:: → The scheduler does not know of your urgency and you have no way of communicating your urgency to the scheduler. Therefore the bwHPC recommends to avoid generating the need for urgent calculations. We however also know that sometimes urgency can not be avoided. In such cases contact the cluster operators to see if they can help you out. Don't ask for this lightly, because if everything is urgent, nothing is!
	:: → Many things have a tendency to avoid obliging to plans. Sudden problems can arise both on the user end and on the cluster end, so having a personal time buffer for such cases is good for anxiety prevention.		:: → Many things have a tendency to avoid obliging to plans. Sudden problems can arise both on the user end and on the cluster end, so having a personal time buffer for such cases is good for anxiety prevention.
			* Be mindful when performing very long calculations. For a multitude of reasons a computation job may suddenly end during the run. The longer the calculation the higher the risk of an unexpected error.
			:: → If possible create checkpoint files regularly during your calculations, from which you can pick up the calculation again.
	\|}		\|}
	<br>		<br>

A Flachmueller: /* Dos and Don'ts */

2026-10-14T12:35:49Z

Dos and Don'ts

← Older revision		Revision as of 14:35, 14 October 2026
Line 86:		Line 86:
	:: → Request a calculation time larger than your estimate. For a new calculation about 20%-30% more time than estimated often is a feasable starting point. Good time estimates are below 10% of extra time requested.		:: → Request a calculation time larger than your estimate. For a new calculation about 20%-30% more time than estimated often is a feasable starting point. Good time estimates are below 10% of extra time requested.
	:: → Having the requested time be close to the actual calculation time is beneficial for the cluster because it helps the scheduler to be more precise and thus shortens idle times.		:: → Having the requested time be close to the actual calculation time is beneficial for the cluster because it helps the scheduler to be more precise and thus shortens idle times.
			* Plan early what calculations you want to perform and create a rough timetable for when you want to submit them. Keep cluster waiting times in mind and ideally have some buffer before important deadlines (e.g. paper submission deadlines).
			:: → The scheduler does not know of your urgency and you have no way of communicating your urgency to the scheduler. Therefore the bwHPC recommends to avoid generating the need for urgent calculations. We however also know that sometimes urgency can not be avoided. In such cases contact the cluster operators to see if they can help you out. Don't ask for this lightly, because if everything is urgent, nothing is!
			:: → Many things have a tendency to avoid obliging to plans. Sudden problems can arise both on the user end and on the cluster end, so having a personal time buffer for such cases is good for anxiety prevention.
	\|}		\|}
	<br>		<br>

A Flachmueller: /* Dos and Don'ts */

2026-10-14T11:55:56Z

Dos and Don'ts

← Older revision		Revision as of 13:55, 14 October 2026
Line 84:		Line 84:
	* Bundle large amounts of tiny calculations (e.g. 1000 short running analyses taking 2 minutes each) together into fewer / a single job(s) that orchestrates them to run consecutively (and maybe even distributes them among different cores)		* Bundle large amounts of tiny calculations (e.g. 1000 short running analyses taking 2 minutes each) together into fewer / a single job(s) that orchestrates them to run consecutively (and maybe even distributes them among different cores)
	* Estimate the total calculation time of your job. A short test run (either on your local machine or on the cluster) can help, though transferability and extrapolation lead to inaccuracies.		* Estimate the total calculation time of your job. A short test run (either on your local machine or on the cluster) can help, though transferability and extrapolation lead to inaccuracies.
	:: → Request a calculation time larger than your estimate. For a new calculation about 20% more time than estimated often is a feasable starting point. Good time estimates are below 10% of extra time requested.		:: → Request a calculation time larger than your estimate. For a new calculation about 20%-30% more time than estimated often is a feasable starting point. Good time estimates are below 10% of extra time requested.
	:: → Having the requested time be close to the actual calculation time is beneficial for the cluster because it helps the scheduler to be more precise and thus shortens idle times.		:: → Having the requested time be close to the actual calculation time is beneficial for the cluster because it helps the scheduler to be more precise and thus shortens idle times.
	\|}		\|}

A Flachmueller at 14:37, 13 October 2026

2026-10-13T14:37:19Z

← Older revision		Revision as of 16:37, 13 October 2026
Line 75:		Line 75:

	→ '''[[Job Monitoring]]'''		→ '''[[Job Monitoring]]'''

			== Dos and Don'ts ==

			There are a number of pitfalls users might encounter when starting to use compute clusters. To avoid some of them, we've collected some best practices in the form of a Dos and Dont's list. It is meant to serve as guidance, not as an absolute imperative, because sometimes stricly avoiding every undesired behaviour is not feasible, though discussing those cases with the cluster operators beforehand is a good idea.

			{\| style="background:#deffee; width:100%; font-size:100%;"
			\|'''Dos:'''
			* Bundle large amounts of tiny calculations (e.g. 1000 short running analyses taking 2 minutes each) together into fewer / a single job(s) that orchestrates them to run consecutively (and maybe even distributes them among different cores)
			* Estimate the total calculation time of your job. A short test run (either on your local machine or on the cluster) can help, though transferability and extrapolation lead to inaccuracies.
			:: → Request a calculation time larger than your estimate. For a new calculation about 20% more time than estimated often is a feasable starting point. Good time estimates are below 10% of extra time requested.
			:: → Having the requested time be close to the actual calculation time is beneficial for the cluster because it helps the scheduler to be more precise and thus shortens idle times.
			\|}
			<br>
			{\| style="background:#FFCCCC; width:100%; font-size:100%;"
			\|'''Don'ts:'''<br>
			* Do not run very short jobs (single digit minutes) on regular compute nodes. Some clusters offer separate partitions for short running jobs.
			:: → For the sake of efficiency small calculations should use few cores and accept runtimes larger than 1 hour.
			:: → If a parallelizable compute job calculates in under 1 hour on 1 core you should check your reasoning why it needs to run on the cluster at all instead of your local machine. Most (if not all) modern consumer machines do have multiple cores available and often have higher clock speeds than cluster CPUs. The true power of modern compute clusters comes from splitting large parallelizable calculations over many compute cores, usually at the cost of somewhat lower core clock speeds.
			* Do not unnecessarily split your calculation into many tiny short running jobs to "trick" the backfilling system by using every 5 minute idle gap that may occur.
			:: → Allocation of a job onto the compute nodes takes up some time for every job, as does cleanup afterwards. Thus by splitting a calculation its overall efficiency decreases accordingly.
			:: → The scheduler assigns and updates priorities and starting times of jobs frequently. A higher number of jobs in the queue means a higher workload for the scheduler, leading to unnecessary strain of the system.
			* Do not request resources that remain unused by your job.
			:: → The Resource Management System calculates your recent usage by multiplying the number of requested compute resources (CPU cores / GPUs) by the time the job was allocated. So if 90% of the cores are idle most of the time or not used at all doesn't matter to the system, it will always use 100% of the requested compute resources for the calculation of the Fair Share Value. For the time it however uses the actual walltime of the jobs.
			:: → Requesting lots of compute resources for a job usually leads to longer waiting times in the queue compared to less resource intensive jobs.
			* Do not spawn too many threads with your jobs. Although multithreading allows some code to run overall more efficient due to better resource usage, spawning too many threads on a compute unit has the contrary effect because the threads have to be managed.
			:: → Be mindful when increasing the thread count and analyse your actual performance gain.
			\|}

A Flachmueller: /* How To Run Jobs Efficiently */

2026-10-09T10:31:24Z

How To Run Jobs Efficiently

← Older revision		Revision as of 12:31, 9 October 2026
Line 70:		Line 70:
	Running calculations on an HPC node consumes a lot of energy. To make the most of the available resources and keep cluster and energy use as efficient as possible please also see our advice for		Running calculations on an HPC node consumes a lot of energy. To make the most of the available resources and keep cluster and energy use as efficient as possible please also see our advice for

	→ '''[[Efficient Cluster Usage]]'''		→ '''[[Energy Efficient Cluster Usage]]'''

	To optimize the job efficiency, it is very helpful to check which resources a job has actually used.		To optimize the job efficiency, it is very helpful to check which resources a job has actually used.

H Schumacher: Added monitoring

2026-07-14T08:32:28Z

Added monitoring

← Older revision		Revision as of 10:32, 14 July 2026
Line 58:		Line 58:
	→ '''[[BinAC2/Slurm \| Slurm BinAC2]]'''		→ '''[[BinAC2/Slurm \| Slurm BinAC2]]'''

	== How to ~~Use~~ ~~Computing Ressources~~ Efficiently ==		== How To Run Jobs Efficiently ==


Line 70:		Line 70:
	Running calculations on an HPC node consumes a lot of energy. To make the most of the available resources and keep cluster and energy use as efficient as possible please also see our advice for		Running calculations on an HPC node consumes a lot of energy. To make the most of the available resources and keep cluster and energy use as efficient as possible please also see our advice for

	→ '''[[~~Energy~~ Efficient Cluster Usage]]'''		→ '''[[Efficient Cluster Usage]]'''

			To optimize the job efficiency, it is very helpful to check which resources a job has actually used.

			→ '''[[Job Monitoring]]'''

K Siegmund: /* Link to Batch System per Cluster */

2026-03-25T09:09:52Z

Link to Batch System per Cluster

@@ Line 25: / Line 25: @@
 &rarr; '''[[Environment Modules]]'''
-== Link to Batch System per Cluster ==
+== Job Script and Job Submission ==
 Because of differences in configuration (partly due to different available hardware), each cluster has their own batch system documentation: