Hi Reuti,
Using h_rt kills the job after the allotted time. Can't this be disabled?
We only want to use it as a rough guide.
Thanks
Regards,
Joseph David Borġ
josephb.org
On 13 January 2014 17:43, Reuti re...@staff.uni-marburg.de wrote:
Am 13.01.2014 um 18:33 schrieb Joe Borġ:
Thanks.
Hi,
Am 15.01.2014 um 11:16 schrieb Joe Borġ:
Using h_rt kills the job after the allotted time.
Yes.
Can't this be disabled?
There is no feature in SGE to extend the granted runtime of a job (I heard such
a thing is available in Torque).
We only want to use it as a rough guide.
If
Hi,
Am 15.01.2014 um 18:55 schrieb Joe Borġ:
I have it working, except even if I put jobs run time as 24 hours, they all
get killed after 6hours 40mins.
6h 40m = 360m + 40m = 400m = 24000s - did you forget by accident the colons
when you defined the limit?
Looking at qstat -j shows the
We have OpenMP jobs that need a user-defined (usually more than one but less
than all) number of cores on a single node for each job. In addition to
running these jobs, our program has an interface to the cluster so they can
submit jobs through a custom GUI (and we build the qsub command in
Am 15.01.2014 um 23:28 schrieb Allison Walters:
We have OpenMP jobs that need a user-defined (usually more than one but less
than all) number of cores on a single node for each job. In addition to
running these jobs, our program has an interface to the cluster so they can
submit jobs
Allison,
I love Grid Engine but this is the one feature I truly miss from Torque:
-l nodes=x:ppn=[count]
Reuti,
We have a complex setup trying to accomplish this same thing and it kind of
works but we have an issue with job not starting when jobs are running on a
subordinate queue.
First,
Sorry - you're correct, I meant -l nodes=1:ppn=[count] . :-)
Hmmm...we've had some requests from clients specifically to support SGE,
but this is a pretty key part of our functionality. Currently we can
submit, but without the way to specify cores, the clients won't get the
timing results
