Changes between Version 15 and Version 16 of WRF4G/ExecutionEnvironments

Timestamp:

Feb 21, 2013 4:38:47 PM (9 years ago)

Author:

carlos

Comment:

--

WRF4G/ExecutionEnvironments

@@ -27 +27 @@
     '''mncancel <job_id>''' removes his/her job from the queue system, canceling the execution of the job if it was already running. 
 
-=== Job directives ===
+=== Job Directives ===
 
 A job must contain a series of directives to inform the batch system about the characteristics of the job. These directives appear as comments in the job script, with the following syntax:
@@ -57 +57 @@
 
 The working directory of your job (i.e. where the job will run). If not specified, it is the current working directory at the time the job was submitted.
+
 {{{
 #!sh
@@ -63 +64 @@
 
 The name of the file to collect the stderr output of the job.
+
 {{{
 #!sh
 #@ output = file
 }}}
+
 The name of the file to collect the standard output (stdout) of the job.
+
 {{{
 #!sh
 #@ total_tasks = number
 }}}
+
 The number of processes to start.
+
 {{{
 #!sh
 #@ cpus_per_task = number
 }}}
+
 The number of cpus allocated for each task. This is useful for hybrid MPI+OpenMP applications, where each process will spawn a number of threads. The number of cpus per task must be between 1 and 16, since each node has 16 cores (one for each thread).
+
 {{{
 #!sh
 #@ tasks_per_node = number
 }}}
+
 The number of tasks allocated in each node. When an application uses more than 3.8 GB of memory per process, it is not possible to have 16 processes in the same node and its 64GB of memory. It can be combined with the cpus_per_task to allocate the nodes exclusively, i.e. to allocate 2, processes per node, set both directives to 2. The number of tasks per node must be between 1 and 16.
+
 {{{
 #!sh
 # @ gpus_per_node = number
 }}}
+
 The number of GPU cards assigned to the job. This number can be [0,1,2] as there are 2 cards per node.
 
@@ -153 +164 @@
 LSF is the utility used at !MareNostrum III for batch processing support, so all jobs must be run through it. This document provides information for getting started with job execution at the Cluster.
 
-=== Submitting jobs ===
+=== Submitting Jobs ===
 A job is the execution unit for LSF. A job is defined by a text file containing a set of directives describing the job, and the commands to execute. Please, bear in mind that there is a limit of 3600 bytes for the size of the text file.
 
-=== LSF commands ===
+=== LSF Commands ===
 These are the basic directives to submit jobs:
 
@@ -165 +176 @@
     '''bkill <job_id>''' remove the job from the queue system, canceling the execution of the processes, if they were still running.
 
-=== Job directives ===
+=== Job Directives ===
 A job must contain a series of directives to inform the batch system about the characteristics of the job. These directives appear as comments in the job script, with the following syntax:
+
 {{{
 #!sh
 #BSUB -option value
 }}}
+
 {{{
 #!sh
 #BSUB -J job_name
 }}}
+
 The name of the job.
+
 {{{
 #!sh
 #BSUB -q debug
 }}}
+
 This queue is only intended for small tests, so there is a limit of 1 job per user, using up to 64 cpus (4 nodes), and one hour of wall clock limit.
+
 {{{
 #!sh
 #BSUB -W HH:MM
 }}}
+
 NOTE: take into account that you can not specify the amount of seconds in LSF. The limit of wall clock time. This is a mandatory field and you must set it to a value greater than the real execution time for your  application and smaller than the time limits granted to the user. Notice that your job will be killed after the elapsed period.
+
 {{{
 #!sh
 #BSUB -cwd pathname
 }}}
+
 The working directory of your job (i.e. where the job will run). If not specified, it is the current working directory at the time the job was submitted.
+
 {{{
 #!sh
 #BSUB -e/-eo file
 }}}
+
 The name of the file to collect the stderr output of the job. You can use %J for job_id. -e option will APPEND the file, -eo will REPLACE the file.
+
 {{{
 #!sh
 #BSUB -o/-oo file
 }}}
+
 The name of the file to collect the standard output (stdout) of the job. -o option will APPEND the file, -oo will REPLACE the file.
+
 {{{
 #!sh
 #BSUB -n number
 }}}
+
 The number of processes to start.
+
 {{{
 #!sh
 #BSUB -R"span[ptile=number]"
 }}}
+
 The number of processes assigned to a node.
 
 We really encourage you to read the manual of bsub command to find out other specifications that will help you to define the job script.
+
 {{{
 #!sh
@@ -221 +250 @@
 
 Sequential job :
+
 {{{
 #!sh
@@ -234 +264 @@
 
 Sequential job using OpenMP :
+
 {{{
 #!sh
@@ -249 +280 @@
 
 Parallel job :
+
 {{{
 #!sh
@@ -267 +299 @@
 
 Parallel job using threads:
+
 {{{
 #!sh
@@ -296 +329 @@
 
 === Running Jobs ===
+
 Slurm+MOAB is the new utility used at Tirant for batch processing support.
-We moved from LoadLeveler and all the jobs must be run through this new
-batch system. We tried to keep it as simple as posible keeping the syntax from the LoadLeveler to make the transition easier to those who used Loadleveler in the past. This document provides information for getting started with job execution at Tirant.
+We moved from !LoadLeveler and all the jobs must be run through this new
+batch system. We tried to keep it as simple as possible keeping the syntax from the !LoadLeveler to make the transition easier to those who used !Loadleveler in the past. This document provides information for getting started with job execution at Tirant.
 
 ==== Classes ====
 
-The user’s limits are assigned automatically to each particular user (depending on the resources granted by the Access Committee) and there is no reason to explicitly set the #@class directive. Anyway you are allowed to use the special class: ”debug” in order to performe some fast short tests. To use the ”debug” class you need to include the #@class directive
-Table 1: Classes
-Class debug Max CPUs 64 CPU Time 10 min Wall time limit 10 min
+The user’s limits are assigned automatically to each particular user (depending on the resources granted by the Access Committee) and there is no reason to explicitly set the #@class directive. Anyway you are allowed to use the special class: "debug" in order to performe some fast short tests. To use the "debug" class you need to include the #@class directive
+
+Table 1: Classes Class debug Max CPUs 64 CPU Time 10 min Wall time limit 10 min
 The specific limits assigned to each user depends on the priority granted
 by the access committee. Users granted with ”high priority hours” will have access to a maximum of 1024 CPUs and a maximum wall clock limit of 72
@@ -312 +346 @@
 Local users of Tirant have access to a new local queue called "class t".
 This queue has same parameters as "class a", but the priority is modified to restrict local time consumption to 20% of total computation time.
- *debug: This class is reserved for testing the applications before submitting them to the 'production' queues. Only one job per user is allowed to run simultaneously in this queue, and the execution time will be limited to 10 minutes. The maximum number of nodes per application
+
+ * debug: This class is reserved for testing the applications before submitting them to the 'production' queues. Only one job per user is allowed to run simultaneously in this queue, and the execution time will be limited to 10 minutes. The maximum number of nodes per application
 is 32. Only a limited number of jobs may be running at the same time
 in this queue.
@@ -330 +365 @@
  * '''mncancel <jobid>''' remove his/her job from the queue system, canceling the execution of the processes, if they were already running.
  * '''checkjob <jobid>''' obtains detailed information about a specific job, including the assigned nodes and the possible reasons preventing the job from running.
- * '''mnstart''' shows information about the estimated time for the especified job to be executed.
+ * '''mnstart''' shows information about the estimated time for the specified job to be executed.
 
 === Job Directives ===
+
 A job must contain a series of directives to inform the batch system about
 the characteristics of the job. These directives appear as comments in the
@@ -340 +376 @@
 # @ directive = value
 }}}
+
 Additionally, the job script may contain a set of commands to execute.
 If not, an external script must be provided with the 'executable' directive.
 Here you may find the most common directives:
+
 {{{
 # @ class = class\_name
 }}}
+
 The partition where the job is to be submitted. Let this field empty
 unless you need to use "interactive" or "debug" partitions.
+
 {{{
 # @ wall_clock_limit = HH:MM:SS
 }}}
+
 The limit of wall clock time. This is a mandatory field and you must set
 it to a value greater than the real execution time for your application and smaller than the time limits granted to the user. Notice that your job will be killed after the elapsed period.
+
 {{{
 # @ initialdir = pathname
 }}}
+
 The working directory of your job (i.e. where the job will run). If not
 specified, it is the current working directory at the time the job was submitted.
+
 {{{
 # @ error = file
 }}}
+
 The name of the file to collect the stderr output of the job.
+
 {{{
 # @ output = file
 }}}
+
 The name of the file to collect the standard output (stdout) of the job.
+
 {{{
 # @ total_tasks = number
 }}}
+
 The number of processes to start.
 
@@ -374 +423 @@
 
 Serial job:
+
 {{{
 #!sh
@@ -388 +438 @@
 
 Parallel job :
+
 {{{
 #!sh