-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exo soft displaced vertices skim #43936
Exo soft displaced vertices skim #43936
Conversation
cms-bot internal usage |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-43936/38803
|
A new Pull Request was created by @LangFelix1 for master. It involves the following packages:
@cmsbuild, @sunilUIET, @AdrianoDee, @miquork can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
Hi @cms-sw/pdmv-l2 , this is an important skim for EXO PAG that should be added to the full ReReco 2022/2023. Could you please trigger it and its backport #43940 ? |
Hi @youyingli, which wfs can we use to test? |
wf = 140.103, 141.103 |
test parameters:
|
please test |
) | ||
|
||
EXOSoftDisplacedVerticesSkimSequence = cms.Sequence( | ||
hltSoftDV * softDVSelection |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
out of curiosity, what's "soft displaced vertices" specific here? It looks more like a skim on the MET values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The skim is for the Soft Displaced Vertices plus MET analysis. Its purpose is to access tracks below the MiniAOD threshold (~1GeV) in order to reconstruct very soft displaced vertices in addition to MET requirements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For my education, is it customary to call the SKIM by the target analysis rather than the actual skimming pattern? I was wondering if this could be useful to other analyses that might get discouraged by the very specific analysis targeted nomenclature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was our understanding, given the different existing skims. But we are open to modify the name if there is a good suggestion. We would just like to avoid a confusion with PDWG_EXOHighMET.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But we are open to modify the name if there is a good suggestion.
I am also genuinely curious about the policy, that's why I asked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checking the other SKIMs I can't say we really have a strict policy for SKIM definition (it's either the analysis either the content). In this case maybe it's a bit odd since the "analysis name" could also be referring to a sort of vertex selection that actually is not there. But I can't think of a quick good alternative (at the moment).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SKIM is usually for special tasks or analyses in POG/PAG (instead of general purpose) since these datasets (RECO, AOD) could not be on disk. Different SKIMs also focus on different data tiers. Therefore, for my understanding, there is no clear policy or role for the name of SKIM but depending on the SKIM proposers to label the purpose of the SKIM. So, the proposers can quickly recognize which datasets are what they want.
I’m not sure if other analyses aren’t relevant to the SKIM purpose but would like to use the same SKIMs. Of course, in case the new proposed SKIM has highly similar event contents and filers, we can suggest adding additional requirements to the existing SKIM config instead of creating the new one.
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-e6a7ec/37373/summary.html Comparison SummarySummary:
|
what is the event rate reduction factor (roughly) due to the pfmet > 140 GeV requirement? |
It's around 0.2 |
At 0.2 is it perhaps cheaper to just split these paths into a separate PD instead of a skim? |
A large part of the reduction is due to MET cut. The reduction resulting from filtering only trigger paths is 0.5. |
The output skim size as 20 % of the original AOD (instead of RECO tier with large data size) is acceptable. And for full ReReco, SKIM could be more straightforward. |
I'm not sure what the status of this PR is. If there is no critical point, it should proceed? |
+pdmv |
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @antoniovilela, @sextonkennedy, @rappoccio (and backports should be raised in the release meeting by the corresponding L2) |
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-e6a7ec/37808/summary.html Comparison SummarySummary:
|
+1 |
PR description:
This PR introduces a new skim called EXOSoftDisplacedVertices, the passing rate has been tested and is around 20%.
The skim works on a selection of MET HLT paths and a requirement on pfMET > 140 GeV
PR validation:
The code has been compiled and tested locally
If this PR is a backport please specify the original PR and why you need to backport that PR. If this PR will be backported please specify to which release cycle the backport is meant for:
Not a backport