Restrict GEM/ME0 cluster size and max N clusters #19986
Conversation
|
A new Pull Request was created by @dildick (Sven Dildick) for master. It involves the following packages: SimMuon/GEMDigitizer @cmsbuild, @civanch, @mdhildreth, @kpedro88, @davidlange6 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: ecef4bd The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: You can see the results of the tests here: I found follow errors while testing this PR Failed tests: RelVals
When I ran the RelVals I found an error in the following worklfows: runTheMatrix-results/20034.0_TTbar_14TeV+TTbar_14TeV_TuneCUETP8M1_2023D17_GenSimHLBeamSpotFull14+DigiFullTrigger_2023D17+RecoFullGlobal_2023D17+HARVESTFullGlobal_2023D17/step2_TTbar_14TeV+TTbar_14TeV_TuneCUETP8M1_2023D17_GenSimHLBeamSpotFull14+DigiFullTrigger_2023D17+RecoFullGlobal_2023D17+HARVESTFullGlobal_2023D17.log20434.0 step2 runTheMatrix-results/20434.0_TTbar_14TeV+TTbar_14TeV_TuneCUETP8M1_2023D19_GenSimHLBeamSpotFull14+DigiFullTrigger_2023D19+RecoFullGlobal_2023D19+HARVESTFullGlobal_2023D19/step2_TTbar_14TeV+TTbar_14TeV_TuneCUETP8M1_2023D19_GenSimHLBeamSpotFull14+DigiFullTrigger_2023D19+RecoFullGlobal_2023D19+HARVESTFullGlobal_2023D19.log The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: |
|
Comparison not run due to runTheMatrix errors (RelVals and Igprof tests were also skipped) |
cmsbuild
added
comparison-notrun
tests-rejected
and removed
comparison-pending
tests-started
labels
cmsbuild
added
comparison-pending
tests-pending
and removed
comparison-notrun
tests-rejected
labels
|
Pull request #19986 was updated. @cmsbuild, @civanch, @mdhildreth, @kpedro88, @davidlange6 can you please check and sign again. |
|
please test |
|
The tests are being triggered in jenkins. |
|
The tests are being triggered in jenkins. |
|
+1 The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: |
|
Comparison job queued. |
|
Comparison is ready Comparison Summary:
|
|
+1 |
|
+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. @davidlange6, @smuzaffar (and backports should be raised in the release meeting by the corresponding L2) |
cmsbuild
added
fully-signed
upgrade-approved
and removed
pending-signatures
upgrade-pending
labels
| unsigned int nClusters = 0; | ||
|
|
||
| // proto collection | ||
| std::vector<std::pair<GEMDetId, GEMPadDigiCluster> > proto_clusters; |
There was a problem hiding this comment.
hi @dildick - could you not do the cleanup of extra digis (presumably not needed all the time..) directly in out_clusters instead of making this intermediate structure?
There was a problem hiding this comment.
@davidlange6 The selection I implemented (maximum first 8 in the list) will need to be optimized for sure. Hardware tests will have to show how to best select GEM/ME0 clusters in realistic conditions. The final selection will likely be very different. With this setup we can simulate the effects of various selection procedures. So in due time we can modify the algorithm to not produce an intermediate proto_clusters
There was a problem hiding this comment.
hi @dildick - sorry for an extremely slow answer. I'd suggest we build this idea in from the beginning.I think its straightforward
- don't declare proto_clusters, just fill out_clusters.
- make a dedicated function for cleaning. -in the current case, its very trivial. But it could then easily grow to meet the more complex needs in the future. (and if you need to copy clusters at that point you could).
A different point - the way maxClusters_ is used below looks potentially incorrect. If it is really meant as the maximum size of what is now protoClusters, then don't let protoClusters grow beyond that size from the beginning. If instead its meant to be the maximum size of the final collection, then the loopmax concept is incorrect. Instead the out_clusters size needs to be checked at the end to see if it is too big.
There was a problem hiding this comment.
Regarding point 1: could you point me to an example how to clean a muondigicollection such as out_clusters?
There was a problem hiding this comment.
ah - sigh - i didn't realize that MuonDigiCollection exposes only a trivial bit of the interface that a standard vector has... i guess its not worth the trouble..
There was a problem hiding this comment.
@davidlange6 what is the plan forward then? Can we go ahead with the current proposal?
There was a problem hiding this comment.
hi @dildick - could you confirm the role of maxClusters?
There was a problem hiding this comment.
max number of clusters (in the cluster digi collection) in a GEM chamber
There was a problem hiding this comment.
Ok, as a folllowup pr, the check on max clusters can be applied directly when making proto_clusters
|
@davidlange6 Can this PR be integrated? |
|
@smuzaffar I will address the code-checks in packages SimMuon/GEMDigitizer, L1Trigger/CSCTriggerPrimitives and L1Trigger/ME0Trigger in a follow-up pull request. I have been waiting for a while now for a signature. |
|
@davidlange6 Can this PR be integrated? |
|
merge |
dildick
deleted the
from-CMSSW_9_3_X_2017-07-31-2300-gem-me0-clustersize-maxclusters
branch
GEM/ME0 cluster size is restricted to
maxClusterSize_and max number of clusters tomaxClusters_. By default both parameters are set to 8 as specified in the GEM TDR and Muon Upgrade TDR. Both GEM chambers (GEMChamber) and ME0 chambers (ME0Layer) are designed to send out max 8 clusters of 8 neighboring trigger pads. In case there are more than 8 clusters, the algorithm selects the first 8. The cluster selection procedure is expected to be optimized later.