[QC-1012] Allow TrendingTaskITSFhr to trend slightly desynchronized objects#1965
Merged
Merged
Conversation
…bjects The FHR Task generates objects specific to particular detector layers. Since detector layers are assigned to different subsets of FLPs, the merged objects do not have common validity, as FLPs do not have QC cycles ideally in sync. Thus we have look for the objects a bit behind and forward from the trigger timestamp as well.
Collaborator
Author
|
tested with some improvised config, seems to work as expected. |
Barthelemy
approved these changes
Sep 4, 2023
Collaborator
Author
|
@iravasen please shout if you do not agree with this solution. |
This file contains hidden or 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
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.
The FHR Task generates objects specific to particular detector layers. Since detector layers are assigned to different subsets of FLPs, the merged objects do not have exactly the same validity, as FLPs do not have QC cycles ideally in sync. Thus we have look for the objects a bit behind and forward from the trigger timestamp as well.
This introduces an configuration parameter
maxObjectTimeShiftMsto allow for certain shift of QC objects coming from the trended task. Normally it should correspond to the cycle length of the latter.