Am 06.08.2012 um 10:33 schrieb Gaya Nadarajan: > <snip> > > I didn't give enough background on my work. My program itself generates the > tasks automatically (using planning) from other programs invoking it with > options passed in, schedules the tasks for execution and monitors their > progress (and updates a DB accordingly). I'm using the DRMAA_API to dispatch > jobs to sge. I'm trying to control this dependency from within my program > itself, which is proving a bit tricky. > > This sounds like a good option, instead of generating and dispatching tasks > for execution one by one using sge setting options, I should generate a > script for each chunk of 3 subtasks and send the script for execution. > Generating task 3 would require a callback to my program which is not that > straightforward right now but I should figure out what would be best to get > things to work. > > Thanks and do post any more comments or suggestions.
Some thoughts: Task 3 will right now be submitted after job 2 finished. Hence he starts to wait right then. It woud be better to submit it right away with an additional user hold, and change the parameters before it's released. I just realized, that there is no option to change the command arguments (job_args in `qstat -j <job_id>`) with `qalter`. A way to circumvent this would be the usage of environment variables (`qalter -v ... <job_id>`) or a job context (`qalter -ac ... <job_id>`). == Thinking in long terms DRMAA v2 will allow to reconnect to a session. It should then be possible to make changes even later on. == Would it help to submit all jobs to an advance reservation which was granted before? As this particular advance reservation is scheduled to an exechost, all jobs submitted to this AR will stay on the same machine. -- Reuti _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
