Hiya,
Some more hand-holding questions from me: I need to run some (3rd party) monitoring/post-processing tasks in parallel to the main run task (monitoring tasks handling run restart logic for funny input; post-processing tasks handling run output needing ~continuous post-processing).
When the main run task completes, I want these monitoring/post-processing tasks to stop.
I need to manage this within cylc, as these monitoring/post-processing tasks are unaware of the status of the main run task - they just run permanently/dumbly.
Various questions:
- These to-be-killed tasks will already be running, so I believe suicide triggers are irrelevant here, as this isn’t about graph manipulation, right?
- All tasks will be rose apps - is the right way to manage the job killing of the to-be-killed tasks still using
cylc kill
? I can’t see anything in the very handy (thanks!) rose cheat sheet which makes me think otherwise! - Even more paranoid/LBYLish - I’ll be targetting (the MO’s) HPC - so pbs. I see the job killing link above says
cylc kill
is for “supported batch systems”. Anything I should worry about here? - Finally, I guess I want to be paranoid about only killing the to-be-killed tasks in the current cycle: I don’t think my cycles should overlap, but I might be wrong! Is there a canonical way for targetting named-task-but-only-from-current-cycle?
- I think I can probably work something out from Hilary’s good suggestion to look at
cylc kill --help
, and from the nice examples there (thanks!). However I think I’m at risk of coding something clunky, where there may be an elegant way of combiningcylc kill
with various cylc/rose env vars, or a judiciousrose date
call. Hence asking about canonical patterns for this!
- I think I can probably work something out from Hilary’s good suggestion to look at
Thanks, Edmund