Changes between Version 14 and Version 15 of WRF4G/ExecutionEnvironments


Ignore:
Timestamp:
Feb 21, 2013 4:10:52 PM (9 years ago)
Author:
carlos
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WRF4G/ExecutionEnvironments

    v14 v15  
    310310hours. If you need to increase these limits please contact the support group.
    311311
    312 Local users of Tirant have access to a new local queue called ”class t”.
    313 This queue has same parameters as ”class a”, but the priority is modified to restrict local time comsumption to 20% of total computation time.
    314  *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
     312Local users of Tirant have access to a new local queue called "class t".
     313This queue has same parameters as "class a", but the priority is modified to restrict local time consumption to 20% of total computation time.
     314 *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
    315315is 32. Only a limited number of jobs may be running at the same time
    316316in this queue.
     
    321321A job is the execution unit for the SLURM. We have created wrappers to
    322322make easier the adaptation to the new batch system to those users who have
    323 already used Tirant and MareNostrum in the past. So the commands are
    324 quite similar to the former Loadleveler commands. A job is defined by a text file containing a set of directives describing the job, and the commands to execute.
     323already used Tirant and !MareNostrum in the past. So the commands are
     324quite similar to the former !Loadleveler commands. A job is defined by a text file containing a set of directives describing the job, and the commands to execute.
    325325
    326326These are the basic directives to submit jobs:
    327327
    328  * '''mnsubmit <jobscript>'''submits a ’job script’ to the queue system (see below for job script direc-tives).
     328 * '''mnsubmit <jobscript>''' submits a 'job script' to the queue system (see below for job script direc-tives).
    329329 * '''mnq''' shows all the jobs submitted.
    330330 * '''mncancel <jobid>''' remove his/her job from the queue system, canceling the execution of the processes, if they were already running.
     
    341341}}}
    342342Additionally, the job script may contain a set of commands to execute.
    343 If not, an external script must be provided with the ’executable’ directive.
     343If not, an external script must be provided with the 'executable' directive.
    344344Here you may find the most common directives:
    345345{{{
    346 # @ class = class\name
     346# @ class = class\_name
    347347}}}
    348348The partition where the job is to be submitted. Let this field empty
    349 unless you need to use ”interactive” or ”debug” partitions.
    350 {{{
    351 # @ wallclocklimit = HH:MM:SS
     349unless you need to use "interactive" or "debug" partitions.
     350{{{
     351# @ wall_clock_limit = HH:MM:SS
    352352}}}
    353353The limit of wall clock time. This is a mandatory field and you must set