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
remove ROOTCLING ifdefs that are no longer needed (were never?) #30748
Conversation
…ing understands c++ - blocks modules build
The code-checks are being triggered in jenkins. |
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-30748/17061
Code check has found code style and quality issues which could be resolved by applying following patch(s)
|
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-30748/17063
|
A new Pull Request was created by @davidlange6 (David Lange) for master. It involves the following packages: DPGAnalysis/SiStripTools @perrotta, @smuzaffar, @Dr15Jones, @makortel, @cmsbuild, @slava77, @jpata, @santocch can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
The tests are being triggered in jenkins.
|
-1 Tested at: 0b6087b CMSSW: CMSSW_11_2_X_2020-07-15-2300 I found follow errors while testing this PR Failed tests: AddOn
I found errors in the following addon tests: cmsDriver.py RelVal -s HLT:GRun,RAW2DIGI,L1Reco,RECO --data --scenario=pp -n 10 --conditions auto:run3_data_GRun --relval 9000,50 --datatier "RAW-HLT-RECO" --eventcontent FEVTDEBUGHLT --customise=HLTrigger/Configuration/CustomConfigs.L1THLT --era Run3 --processName=HLTRECO --filein file:RelVal_Raw_GRun_DATA.root --fileout file:RelVal_Raw_GRun_DATA_HLT_RECO.root : FAILED - time: date Thu Jul 16 18:50:22 2020-date Thu Jul 16 18:38:16 2020 s - exit: 34304 |
Comparison job queued. |
interesting.. so how does one go from path[21] (or 28 or 29) to cff for that filter? |
ok, the job log which are using Multiplicities.h |
I begin to reach the conclusion that this PR fixes rather than breaks. Eg, we have a met filter that computes two multiplicities in tracker and flags In the current test workflows I looked at (136.731), these never fire. however, printouts suggest that it should Eg, in the first few events I see anyway, its a bit deep into StringCutObjectParser for me to be confident in not missing something. (but if so - have these filters been used in run2?) |
Thanks for the investigations @davidlange6 ! Is it known why the behaviour of the multiplicities changes with the removal of the cling defs? As for if these paths have been used and what the change in output entails, perhaps @mtosi @JanFSchulte know? thanks. |
I don’t, no. I’m not familiar with how the cut parser relies on dictionaries @Dr15Jones maybe does? The class structure here is quite different with and without the defs (which means the dictionary looked different than the class object in memory)
On Jul 22, 2020, at 1:59 PM, Joosep Pata <notifications@github.com<mailto:notifications@github.com>> wrote:
Thanks for the investigations @davidlange6<https://github.com/davidlange6> ! Is it known why the behaviour of the multiplicities changes with the removal of the cling defs?
As for if these paths have been used and what the change in output entails, perhaps @mtosi<https://github.com/mtosi> @JanFSchulte<https://github.com/JanFSchulte> know?
thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#30748 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABGPFQYCLJ7YWU5OEAPITRTR43IANANCNFSM4O4CR2RQ>.
|
the cut should reflect outliers in the 2D plot which summaries the correlation between the strip and pixel clusters multiplicities https://tinyurl.com/y2fa4494 |
Yes, its input to a MET filter, which is what’s showing a monitoring difference
On Jul 22, 2020, at 2:56 PM, mia tosi <notifications@github.com<mailto:notifications@github.com>> wrote:
ciao, sorry for this naive question,but
https://cmssdt.cern.ch/dxr/CMSSW/source/DPGAnalysis/SiStripTools/plugins/ByMultiplicityEventFilter.cc#97
is a "standard" EDFilter ? I mean, it adds a flag into the Event and then return the boolean
is this boolean used as in the EDFilters ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#30748 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABGPFQ6DE25JKJSI6Z3BJS3R43OZJANCNFSM4O4CR2RQ>.
|
the code https://cmssdt.cern.ch/dxr/CMSSW/source/DPGAnalysis/SiStripTools/plugins/ByMultiplicityEventFilter.cc#47 are you telling me that it returns True regardless of the results of the expression ? |
You can see that from the monitoring plots here for example
https://cmssdt.cern.ch/SDT/jenkins-artifacts/baseLineComparisons/CMSSW_11_2_X_2020-07-21-1100+7ea8b7/37901/validateJR.html
On Jul 22, 2020, at 3:02 PM, mia tosi <notifications@github.com<mailto:notifications@github.com>> wrote:
the code https://cmssdt.cern.ch/dxr/CMSSW/source/DPGAnalysis/SiStripTools/plugins/ByMultiplicityEventFilter.cc#47
is an EDFilter which adds a flag w/ the result of the expression and returns the boolean itself
are you telling me that it returns True regardless of the results of the expression ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#30748 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABGPFQ6R6ESQ6WNAMSPMAXDR43PNBANCNFSM4O4CR2RQ>.
|
similar cut is applied in the offline reco, actually it was supposed to be applied it is true that some LLP might find interesting some off-diagonal events and therefore, we would really want to remove these flags from the MET filters |
No clue |
The cut parser uses the dictionary to associate the names of functions (which are in the cut) to the actual functions to be called. If the use of |
Its pretty clear that the goal was to isolate everything in the class not needed to evaluate the function call from the root dictionary. This includes member data changes. There are a variety of PRs doing this dating from 2013 and 2014… Some were as part of the root6 migration clearly - so possibly this broke in run2 where it looks like the filter is also not desired for detector reasons (well, I guess that was only after 2017)
On Jul 22, 2020, at 3:48 PM, Chris Jones <notifications@github.com<mailto:notifications@github.com>> wrote:
I don’t, no. I’m not familiar with how the cut parser relies on dictionaries @Dr15Jones<https://github.com/Dr15Jones> maybe does? The class structure here is quite different with and without the defs (which means the dictionary looked different than the class object in memory)
The cut parser uses the dictionary to associate the names of functions (which are in the cut) to the actual functions to be called. If the use of #define lead to a one definition rule violation then we are in compiler undefined territory.
|
@davidlange6 thanks for that summary. For completeness, could you drop a hint here how you traced the issue exactly to the modules
When I produce the job log with |
On Jul 23, 2020, at 4:36 PM, Joosep Pata <notifications@github.com<mailto:notifications@github.com>> wrote:
@davidlange6<https://github.com/davidlange6> thanks for that summary. For completeness, could you drop a hint here how you traced the issue exactly to the modules
trkPOGFilters
trkPOG_manystripclus53X
trkPOG_toomanystripclus53X
When I produce the job log with process.options.wantSummary=True, I only find the TrigReports for the generic trigger paths, not the granular triggers/cffs, so I must be missing something. Thanks!
With wantSummary you should have the output of each path in the job. Reco+Mini has a main path plus a path for each met filter (and skims and alcas and…). The counting of those paths is apparently the same as in the histogram. Eg
TrigReport 1 28 100 100 0 0 Flag_trkPOG_manystripclus53X
Then RecoMET/METFilters has the definitions of the paths
|
Per David's quick investigations above (thx for the tips!), I also confirm that this PR seems to change the behaviour in trkPOGFilters, trkPOG_manystripclus53X, trkPOG_toomanystripclus53X in a number of investigated events. I observe on the workflow
(full logs in which seems rather like a different input ( |
hi @jpata - I think you are correct - I must have miss understand the log. I gather these multiplicities are subdet=5 (aka, Pixel) and subdet=0 (aka, Strip) with the number of clusters from clusterSummaryProducer as the metric. Is 0 expected for one of these (mult2 is nominally strips if I got it right)? |
When I print out the raw data in https://github.com/cms-sw/cmssw/blob/master/DataFormats/TrackerCommon/interface/ClusterSummary.h#L109 the behaviour in the base release seems incorrect as you point out. The multiplicity vectors contain valid numbers, however, the Now the question is how to proceed. Would it be viable to merge this PR which fixes a bug but changes previous behaviour? |
The Multiplicities data structure contains physical and valid data up until the call to This further points to the fact that the base release has undefined behaviour, which could be due to conflicting class definitions between the dictionaries as interpreted by cling and compiled by gcc (as suggested by Chris). The behaviour of There seems to be one other spot in cmssw where |
Yes, I opened a PR for that which has some runtime issues that I’ve yet to understand..
There seems to be one other spot in cmssw where #ifdef __ROOTCLING__ is used to substantially change the class: https://github.com/cms-sw/cmssw/blob/master/DataFormats/Common/interface/DetSetVectorNew.h#L13.
|
+1
|
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. @silviodonato, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
given that cling understands c++ - changes block modules build. There is one more case in DataFormats/Common that changes class definition so we are still looking at that one.