Cluster Installation: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
The following does ''not'' refer to the [http://xds.mpimf-heidelberg.mpg.de/html_doc/xds_parameters.html#CLUSTER_NODES= CLUSTER_NODES=] setup. The latter does ''not'' require a queueing system! | The following does ''not'' refer to the [http://xds.mpimf-heidelberg.mpg.de/html_doc/xds_parameters.html#CLUSTER_NODES= CLUSTER_NODES=] setup. The latter does ''not'' require a queueing system! | ||
XDS can be run in a cluster using any | XDS can be run in a cluster using any batch job scheduling software such as Grid Engine, Condor, Torque/PBS, LSF, SLURM etc. These are distributed resource management system which monitor the CPU and memory usage of the available computing resources and schedule jobs to the least used computers. | ||
== setup of XDS for a batch queue system == | == setup of XDS for a batch queue system == | ||
In order to setup XDS for a queuing system, the ''forkxds'' script needs to be changed to | In order to setup XDS for a queuing system, the ''forkxds'' script needs to be changed to use qsub instead of ssh. Example scripts used for Univa Grid Engine (UGA) at Diamond (from https://github.com/DiamondLightSource/fast_dp/tree/master/etc/uge_array - thanks to Graeme Winter!) are below; they may need to be changed for the specific environment and queueing system. | ||
<pre> | <pre> | ||
Line 67: | Line 67: | ||
</pre> | </pre> | ||
<pre> | <pre> | ||
Line 83: | Line 84: | ||
echo $SGE_TASK_ID | $JOB | echo $SGE_TASK_ID | $JOB | ||
</pre> | </pre> | ||
== Performance == | |||
For the qsub command at the end of the script, it is not necessary to stick to the value of maxcpu as provided by $2 of forkxds (which is supplied by xds_par). If the cluster has nodes with more cores than the node where xds_par was started, it may be more efficient to override maxcpu, by grep-ing MAXIMUM_NUMBER_OF_PROCESSORS from XDS.INP, or by supplying it to the script from an environment variable, or to hard-code the value. If the cluster is homogeneous then this is of course no concern. |
Revision as of 11:06, 10 August 2017
The following does not refer to the CLUSTER_NODES= setup. The latter does not require a queueing system!
XDS can be run in a cluster using any batch job scheduling software such as Grid Engine, Condor, Torque/PBS, LSF, SLURM etc. These are distributed resource management system which monitor the CPU and memory usage of the available computing resources and schedule jobs to the least used computers.
setup of XDS for a batch queue system
In order to setup XDS for a queuing system, the forkxds script needs to be changed to use qsub instead of ssh. Example scripts used for Univa Grid Engine (UGA) at Diamond (from https://github.com/DiamondLightSource/fast_dp/tree/master/etc/uge_array - thanks to Graeme Winter!) are below; they may need to be changed for the specific environment and queueing system.
# forkxds #!/bin/bash # forkxds Version DLS-2017/08 # # enables multi-tasking by splitting the COLSPOT and INTEGRATE # steps of xds into independent jobs. Each job is carried out by # a Fortran main program (mcolspot, mcolspot_par, mintegrate, or # mintegrate_par). The jobs are distributed among the processor # nodes of the NFS cluster network. # # 'forkxds' is called by xds or xds_par by the Fortran instruction # CALL SYSTEM('forkxds ntask maxcpu main rhosts'), # ntask ::total number of independent jobs (tasks) # maxcpu ::maximum number of processors used by each job # main ::name of the main program to be executed; could be # mcolspot | mcolspot_par | mintegrate | mintegrate_par # rhosts ::names of CPU cluster nodes in the NFS network # # DLS UGE port of script to operate nicely with cluster # scheduling system - will work with any XDS usage but is # aimed for fast_dp see fast_dp#3. Options passed through environment: # # FORKXDS_PRIORITY - priority within queue, e.g. 1024 # FORKXDS_PROJECT - UGE project to assign for this # FORKXDS_QUEUE - queue to submit to ntask=$1 #total number of jobs maxcpu=$2 #maximum number of processors used by each job main=$3 #name of the main program to be executed rm -f forkxds.params itask=1 while test $itask -le $ntask do echo $main >> forkxds.params itask=`expr $itask + 1` done # save environment echo "PATH=$PATH" > forkxds.env echo "LD_LIBRARY_PATH=$LD_LIBRARY_PATH" >> forkxds.env # check environment for queue; project; priority information qsub_opt="" if [[ -n "$FORKXDS_PRIORITY" ]] ; then qsub_opt="$qsub_command -p $FORKXDS_PRIORITY" fi if [[ -n "$FORKXDS_PROJECT" ]] ; then qsub_opt="$qsub_command -P $FORKXDS_PROJECT" fi if [[ -n "$FORKXDS_QUEUE" ]] ; then qsub_opt="$qsub_command -q $FORKXDS_QUEUE" fi qsub $qsub_opt -sync y -V -cwd -pe smp $maxcpu -t 1-$ntask `which forkxds_job`
# forkxds_job #!/bin/bash params=$(awk "NR==$SGE_TASK_ID" forkxds.params) JOB=`echo $params | awk '{print $1}'` # load environment . forkxds.env export LD_LIBRARY_PATH=$LD_LIBRARY_PATH export PATH=$PATH echo $SGE_TASK_ID | $JOB
Performance
For the qsub command at the end of the script, it is not necessary to stick to the value of maxcpu as provided by $2 of forkxds (which is supplied by xds_par). If the cluster has nodes with more cores than the node where xds_par was started, it may be more efficient to override maxcpu, by grep-ing MAXIMUM_NUMBER_OF_PROCESSORS from XDS.INP, or by supplying it to the script from an environment variable, or to hard-code the value. If the cluster is homogeneous then this is of course no concern.