Conversation
…amework Late Tasks can create new MonitorObjects based on existing MOs and QOs in the QC workflow. I called them "late", because they would be typically executed close to the end of the processing chain. When running QC workflows distributed over multiple nodes, with Mergers combining the results, they can be used to process the merged results. The adequate use cases involve: * creating trends and correlations from other MonitorObjects and QualityObjects (trending a histogram average, trending quality) * creating plots which can only be constructed from merged objects (ratios, visualizations, ...) * creating summary canvases of QualityObjects available in the QC workflow They are meant to slowly replace Post-Processing, at least in the use cases mentioned above.
305c575 to
1541053
Compare
knopers8
changed the title
Barthelemy
left a comment
Barthelemy
left a comment
There was a problem hiding this comment.
First of all, let me apologize for this very late review.
This is a great job! Thank you.
The late tasks have clearly the potential to replace the PostProcessing tasks in many cases.
I have put a few questions and comments that I let you address.
|
|
||
| void LateTaskRunner::onStop(framework::ServiceRegistryRef services, const Activity& activity) | ||
| { | ||
| mTask->endOfActivity(activity); |
There was a problem hiding this comment.
One last question: should we publish one last time after the user code has been called ? in case they changed something on the plot ?
There was a problem hiding this comment.
Thank you, good point. My initial thinking was that there would not be new data in plots, so there is no point in publishing, but indeed someone might want to e.g. "beautify" a plot at run stop.
I'll add it.
There was a problem hiding this comment.
Well, it's not that simple, DPL does not allow to publish objects at onStop, which probably makes sense. What is possible, is to call endOfActivity and publish objects the last time at onEndOfStream. but I have to check if the two DPL callbacks have guaranteed order and whether both are always executed.
This branch has not been deployed
2 participants
Late Tasks can create new MonitorObjects based on existing MOs and QOs in the QC workflow.
I called them "late", because they would be typically executed close to the end of the processing chain.
When running QC workflows distributed over multiple nodes, with Mergers combining the results, they can be used to process the merged results.
The adequate use cases involve:
They are meant to slowly replace Post-Processing, at least in the use cases mentioned above.
Needs #2660 to have [WIP] removed.