[QC-910] Moving windows in asynchronous QC #2014
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit allows to create objects containing data points for adjacent time windows alongside of having an integrated object for the whole run. The window length is set by the usual "cycleDurationSeconds" parameter and the windows are guaranteed not to overlap. The generated objects can be subject to Checks, just as integrated objects. Technically, the commit brings a few major changes as well: - The decision on finishing a cycle is now up to Timekeeper (excluding end of stream), which is still timer-based in sync QC, but data-driven in async QC, i.e. a new cycle is started when a sample does not fall into currently processed window. - The QC file I/O has been refactored by bringing it into a dedicated class - The QC file structure was reorganized by having two directories at the top - "int" and "mw". The first contains the integrated plots in the usual structure. The latter contains moving windows in the hierarchy "mw/<DET>/<TASK>/<MW START>". This should allow for easy usage by any user scripts (at the cost of a bit more complex walking algorithms for reading it back in the QC chain)
|
an example file structure for ITS Clusters task with 30s window with two plots as moving windows. |
|
Hi @knopers8, thanks a lot! Sorry I missed your message! I see the timestamps are from Sept 20th, does it mean that the timestamps are taken relative to when the run started? I mean, are they taken from the TFs? |
|
Hi @iravasen, the timestamps are unix timestamps in ms (since epoch). They are computed based on TF IDs, nOrbitPerTF and SOR time from the CCDB ( |
|
Thank you, sounds already good like this to me. Don't know about the difference in seconds between SOR and |
Barthelemy
approved these changes
Oct 19, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit allows to create objects containing data points for adjacent time windows alongside of having an integrated object for the whole run. The window length is set by the usual "cycleDurationSeconds" parameter and the windows are guaranteed not to overlap. The generated objects can be subject to Checks, just as integrated objects.
Technically, the commit brings a few major changes as well:
mw/<DET>/<TASK>/<MW START>. This should allow for easy usage by any user scripts (at the cost of a bit more complex walking algorithms for reading it back in the QC chain)