EXOnanoAODv1 producers and setup#48502
Conversation
|
cms-bot internal usage |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-48502/45439
|
|
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-48502/45445
Code check has found code style and quality issues which could be resolved by applying following patch(s)
|
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-48502/45446
|
|
Pull request #48502 was updated. |
|
enable nano |
|
please test |
|
-1 Failed Tests: Build ClangBuild BuildI found compilation warning when building: See details on the summary page. Clang BuildI found compilation warning while trying to compile with clang. Command used: See details on the summary page. |
battibass
left a comment
There was a problem hiding this comment.
Here is another round of comments that can be addressed rather easily
There was a problem hiding this comment.
"segmentLabel" I would suggest: "dtSegmentLabel" (as also CSC segments exist, better saying explicitly these are DT ones)
There was a problem hiding this comment.
Why not return -1? iJet is never updated
There was a problem hiding this comment.
I would pass all of these by reference. Why do you need to use pointers?
There was a problem hiding this comment.
This is equivalent to:
if (daughter.charge() == 0 || daughter.fromPV() < 2 || reco::deltaR(daughter, *cand) > 0.4 || !daughter.hasTrackDetails()) { continue; }There was a problem hiding this comment.
if (el.gsfTrack().isNull() || el.pt() < 7 || fabs(el.eta()) > 2.5){ continue; }There was a problem hiding this comment.
As above, please combine in a single if.
There was a problem hiding this comment.
Why passing pointers? Can't you simply use references?
There was a problem hiding this comment.
if (daughter.charge() == 0 || daughter.fromPV() < 2 || reco::deltaR(daughter, *cand) > 0.4 !daughter.hasTrackDetails()) { continue; }|
+1 Size: This PR adds an extra 16KB to repository The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic:
You can see more details here: Comparison SummarySummary:
Nano size comparison Summary:
NANO Comparison SummarySummary:
|
|
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-48502/48490
Code check has found code style and quality issues which could be resolved by applying following patch(s)
|
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-48502/48491
|
|
Pull request #48502 was updated. @AdrianoDee, @DickyChant, @antoniovagnerini, @battibass, @cmsbuild, @ftorrresd, @miquork can you please check and sign again. |
Thanks for the comments @battibass; all of them should have been addressed now. |
|
@cmsbuild please test |
|
again... you have to test this PR with cms-data/RecoTauTag-TrainingFiles#16 or the tests will fail, see above |
|
@jalimena #48502 (comment) already set the test parameters |
|
ah ok cool my bad @tvami |
|
+1 Size: This PR adds an extra 16KB to repository The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic:
You can see more details here: Comparison SummaryThere are some workflows for which there are errors in the baseline: Summary:
Nano size comparison Summary:
NANO Comparison SummarySummary:
|
There was a problem hiding this comment.
This is my last comment. test_vector is called within the produce method. Throwing an exception if a value is not meaningful looks to me a quite drastic approach.
Isn't there any default value you could assign (i.e. if scores are >0 a negative number would be likely enough) instead of doing that?
There was a problem hiding this comment.
Rather than returning an invalid number, it would be better to have the function return a std::optional<>. That will properly express when something fails and avoids accidentally trying to use an invalid value.
There was a problem hiding this comment.
Indeed you are right, std::optional<> is a better option.
|
Milestone for this pull request has been moved to CMSSW_17_0_X. Please open a backport if it should also go in to CMSSW_16_1_X. |
|
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-48502/48891
Code check has found code style and quality issues which could be resolved by applying following patch(s)
|
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-48502/48892
|
|
Pull request #48502 was updated. @AdrianoDee, @DickyChant, @antoniovagnerini, @battibass, @cmsbuild, @ftorrresd, @miquork can you please check and sign again. |
|
@cmsbuild please test |
|
+1 Size: This PR adds an extra 16KB to repository Comparison SummarySummary:
Nano size comparison Summary:
NANO Comparison SummarySummary:
|
|
+xpog |
|
As agreed during the xPOG meeting, this is a first step in integrating the EXOnano flavour in CMSSW. Investigations into possible optimisation of the event size and into changes that allow the production of EXOnano from MiniAOD (currently works with AOD) are expected as a later step. In addition, matters regarding the large-scale central production of EXOnano will also have to be agreed upon with PPD. |
Thanks a lot! We agree that we will investigate possibilities of the production of EXOnano from MiniAOD for future EXOnano versions (this will likely to based on a extended MiniAOD in the future as we discussed during the xPOG meetings). For our current setting, we are wondering whether there are additional actions we should take to have this PR merged? |
From xpog we don't have any other request before merging. |
PR description:
This PR includes producers and setup for a first version of EXO PAG customizations of nanoAOD, with customization combined from multiple analysis teams working with long-lived particles, including:
Previously discussed at the nanoAOD deep dive, within XPOG April 2 2025 and July 9 2025, and within EXO at the EXO workshop and general meeting.
The PR depends on cms-data/RecoTauTag-TrainingFiles#15 PR with training data for the displaced tau tag.
PR validation:
Collections with number of variables and sizes for different datasets has been evaluated:

Timing study done for running AOD -> EXOnanoAODv1 in one step tested on one file from TTto4Q MC dataset, accounting for differences on different machines. The study shows the relative time difference between producing standard nanoAOD and EXOnanoAODv1 as a function of number of events, with less than a factor 2 relative time increase.

The test script PhysicsTools/NanoAOD/test/test-exoNano.sh runs CMS driver command for AOD->EXOnanoAODv1 in one step (with --step PAT,NANO:(at)EXO) and works for this setup.
@enibigir @jniedzie