You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, our BEAST WDL task dumps its primary outputs (BEAST log and trees files) to local files and then delocalizes them at the end by standard wdl File descriptors in the output block.
However, there are many times in which a BEAST run might prematurely terminate, especially since they tend to run so long. In these cases, we lose the entire (expensive) run.
Ideally it would be nice if we could somehow funnel the outputs through stdout instead. WDL allows for task outputs to be derived from stdout, and most cloud executors like PAPI2 and dnanexus make a point of checkpointing stdout on a frequent basis. This would mean that if a running beast job was prematurely terminated for any reason, we would still have a deserialized copy available in a bucket.
The main challenge though is to figure out how to get both of the critical output files (.trees and .log) through a single pipe (leaving stderr untouched for the usual messages).
The text was updated successfully, but these errors were encountered:
Currently, our BEAST WDL task dumps its primary outputs (BEAST log and trees files) to local files and then delocalizes them at the end by standard wdl File descriptors in the output block.
However, there are many times in which a BEAST run might prematurely terminate, especially since they tend to run so long. In these cases, we lose the entire (expensive) run.
Ideally it would be nice if we could somehow funnel the outputs through stdout instead. WDL allows for task outputs to be derived from stdout, and most cloud executors like PAPI2 and dnanexus make a point of checkpointing stdout on a frequent basis. This would mean that if a running beast job was prematurely terminated for any reason, we would still have a deserialized copy available in a bucket.
The main challenge though is to figure out how to get both of the critical output files (.trees and .log) through a single pipe (leaving stderr untouched for the usual messages).
The text was updated successfully, but these errors were encountered: