Hot answers tagged


I know this is an old question, but the correct command to move a queued job from one queue to another in torque is "qmove" and not qalter. From man page: Usage: qmove destination job_identifier ... Description: To move a job is to remove the job from the queue in which it resides and instantiate the job in another queue. The qmove command issues ...


In Torque only this works: qalter <jobid> -W queue=<new queue name>


If you need a guarantee, submit element zero as a separate job and make 1-9 dependent on its completion.

2 says that all processes associated with the job are killed. I believe that is true for all schedulers since it is clearly the desired behavior. Torque will not kill the job or the child processes when the original process exists, as this would prevent a job from launch one program after ...


do you happen to have any non-comment lines in your batch script before the #PBS -o line? TORQUE will ignore any #PBS lines that occur after the first executable statement in the script. The qsub command will scan your batch script for #PBS lines until it encounters a line that is not a comment or whitespace.


old question, but I'm adding some additional information for anyone that lands here from Google Note that once a job is running in TORQUE, any request to lengthen the walltime will be ignored unless the qalter command is executed by a TORQUE manager or operator. To extend the walltime of a running job, you must contact an administrator. You can shorten ...


I think what you're trying to do is totally reasonable. I don't think there's any problem running your ea_loop script on the head node provided it's doing mostly control level operations like submitting jobs and checking for completion, etc. Can you wrap your EA operations that take ~60 seconds into a small job that's submitted through PBS instead of trying ...


You're using the wrong tool for this kind of operation. PBS schedules individual jobs, but it's intended to deal with jobs of the kind "run the optimization algorithm", not "run one function evaluation". My suggestion to implement this kind of algorithm is to build on MPI and write it as a master-slave [1] algorithm where the slaves do ...


While not a direct answer to your question, have you considered using a library which manages the parallelization for you like Pagmo? Presumably, then you just need to request a certain amount of resources from the scheduler on your cluster.


If you system does not have a job launcher facility (or if PBS does not have that built in) you can do a couple of things. Start all 16 processes, and hope that the OS will nicely spread them over the cores. Start all 16 processes, but prefix them with numactl to fix them to a certain core. Use mpirun but with the following script: mpi -np 16 ...

Only top voted, non community-wiki answers of a minimum length are eligible