fsl.check_first(): Second attempt at refinement#2609
Conversation
|
This didn't work and I don't know enought python to fix it: |
|
Whoops sorry, that was me ruining correspondence between code tested and code pushed. 18e5910 should at least resolve that. On my own system |
|
I get the same. I wasn't aware of any fsl_sub halting functionality. You could submit a job with a hold on the last FIRST JobID that, for example, creates a file indicating that everything has completed and then check for the presence of that file if you don't want to interact with qstat directly. |
The thought had crossed my mind. Just wary of the extent to which this is becoming increasingly clumsy. Decided to avoid |
|
That worked. Thanks for your efforts here. |
Conflicts: lib/mrtrix3/fsl.py
- #2968: Absent - #3049: Absent - #2767: Partially absent - # 3027: Almost all absent (the new tests were in place but that was all) - #3047: Absent - #3071: Absent - #3011: Fill in gaps of changes that were applied to #3011 prior to its derivation from #2917. - #2609: Fixed a couple of small omissions. - #2602: Bits and pieces missing.
Response to suggestion by @glasserm in #2597.
fsl_subseemingly has a built-in functionality for halting execution until all asynchronous jobs have been completed. Hopefully grabbing the job ID of the final executed job inrun_first_alland waiting on that will be sufficient.What I don't know is the point in time at which this functionality was added to
fsl_sub, and therefore whether this change will only work on some minimum version of FSL. But failures of this test should be caught andcheck_first()will revert to prior behaviour.Requires testing on a functioning SGE cluster.