Differences

This shows you the differences between two versions of the page.

--- pbs-dummies [2010/12/17 12:55] – damir
+++ pbs-dummies [2015/11/16 11:33] (current) – external edit 127.0.0.1
@@ Line 2: / Line 2: @@
 ===== for Dummies =====
-**1st thing you need to know:** Using a pbs script is like if you're doing the commands from a shell therefore, if after the login, you need to change dir to launch the job from the shell, you'll need to do it even from the script.\\
+**1st thing you need to know:** Using a pbs script it's like if you're typing the commands from a shell. Therefore you must include in the script all the command that you wuold use on the shell before/after running your program (if after the login you need to change directory to launch the job, you'll need to do it even from the batch script).\\
 \\
 Every instruction line for the queue manager start with #PBS, so\\
@@ Line 10: / Line 10: @@
 The mandatory directives that you must **always** include in the scripts are:
-  - Your email address. the official epfl address or something else, but must be a valid (worldwide) email address.
+  - Your email address. the official epfl address or something else, but must be a valid (worldwide) email address. **This address mus be always present, no matter if you instruct the system to send or not the email messages**.
-  - How much time your job must run (if the job runs over this limit the cluster manager will stop it). the minimum is 1 minute and there's no maximum limit.
+  - How much time your job must run (if the job runs over this limit the cluster manager will kill it). the minimum is 1 minute and there's no maximum limit.
-  - How much memory (RAM) your job will use. Please remember that if your job use more memory than the limit you put here the cluster manager will kill the job. the minimum is 512 Mbyte, currently (as for Dec 2010) the maximum is ~64 Gbyte.
+  - How much memory (RAM) your job will use. Please remember that if your job use more memory than the limit you put here the cluster manager will kill the job. the minimum is 512 Mbyte, currently (as for Jul 2015) the maximum is 64 Gbyte.
+  - How many cores/cpu must be reserved for your job. If you don't include this parameter only one core/cpu will be assigned to your job and you cannot run more than a single threaded job.
 The beginning of your script will be:
 <code>
 # you email address
-#PBS -M <my email address that everyone can use to send emails>
+#PBS -M <my email address that everyone, around the world, can use to send email messages to me>
 # how much time this process must run (hours:minutes:seconds)? 4 hours for this example
 #PBS -l cput=04:00:00
@@ Line 23: / Line 24: @@
 #PBS -l mem=1024mb
 </code>
+If your job is running a simulation that is multithreaded, you can use more than one cpu/core by indicating the number of cores you want with:
+<code>
+#Numer of cores needed by the application (8 in this example)
+#PBS -l ppn=8
+</code>
-After this then you can add directives for instructing the system about the messages you
+After this //prolog// you can add directives for instructing the system about the messages you
 want to receive:
@@ Line 35: / Line 42: @@
 </code>
-Also you can tell the PBS where you want to put the output and errors messages. By default the cluster will put the output and errors messages in 2 separate files (<name of the job>.e<jobID> and <name of the job>.o<jobID>), but maybe you prefer to have all these messages in one single file (<name of the job>.o<jobID>)
+Also you can tell the PBS where you want to put the output and errors messages. By default the cluster will put the output and errors messages in 2 separate files (<name of the job>.e<jobID> for errors and <name of the job>.o<jobID> for the output), but maybe you prefer to have all these messages in one single file (<name of the job>.o<jobID>)
 <code>
@@ Line 42: / Line 49: @@
 </code>
-And then you want to assign a name to your job, so you can know what the cluster is doing for you when you look at the list of running jobs.
+And then you might want to assign a name to your job, so you will know what the cluster is doing for you when you look at the list of running jobs (using the command ''qstat -an1'').
 <code>
@@ Line 66: / Line 73: @@
 </code>
-Another thing to remember is that the output files (the ...o<jobID> and ....e<jobID>) created by the PBS system are placed inside the directory **from where you submitted the job**, not inside the directory from where the program is launched by the script (in other words all the "cd ..." directives inside the script doesn't matter for the queue manager).
+Another thing to remember is that the output files (the ...o<jobID> and ....e<jobID>) created by the PBS system are placed inside the directory **from where you submitted the job**, not inside the directory from where the program is launched by the script (in other words all the "cd ..." directives inside the script aren't considered by the queue manager).
-Once we attach all the lines from above we have a scritp that will look like this:
+Once we attach all the lines from above we'll have a script that will look like this:
 <code>
 #PBS -M <my email address that everyone can use to send emails>
 #PBS -l cput=04:00:00
 #PBS -l mem=1024mb
+#PBS -l ppn=8
 # you want to receive an email messages when your job is started and when it's
 finished (or blocked)
@@ Line 92: / Line 100: @@
 </code>
-Now you just need to tell the cluster system that you want to run this job, but how you do that ? pretty simple, you use the command qsub (it's for queue submit) followed by the name of the script you just created. If you saved the previous example script as test1.pbs in the current directory, you will want to launch this command from the shell:
+Now you just need to tell the cluster system that you want to run this job, but how you do that? pretty simple, you use the command qsub (short for queue submit) followed by the name of the script you just created. If you saved the previous example script as test1.pbs in the current directory, you will want to launch this command from the shell:
 <code>
@@ Line 98: / Line 106: @@
 </code>
-If you like, you can use the absolute path to indicate the script to launch, but **remember** that the output files will be written inside the directory from where you launch the qsub program.\\
+<note>
+If you like, you can use the absolute path to indicate the script to launch, but **remember** that the output files will be written inside the directory from **where** you executed the qsub program.
+</note>
-After all this work, you just need to relax and wait until you receive the email messages from the queuing manager. At this point you return to the directory where the output files are saved and you can check the results.\\
+After all this work, you just need to relax and wait until you receive the email messages from the queuing manager telling you about success or failure. At this point you return to the directory where the output files are saved and check the results.\\
-If you browse the the documentation we have on [[sge|Batch Queuing System]] you'll find examples on how to use Matlab or Mathematica and some explanation about the directives and the commands you can use to use the queuing system.
+If you browse the the documentation we have on [[sge|Batch Queuing System]] you'll find examples on how to use Matlab or Mathematica and some explanation about the directives and the commands available for the queuing system.