-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Fix broken LCTs reported in HLT_L1SingleMu25 [11_1_X] #30914
Fix broken LCTs reported in HLT_L1SingleMu25 [11_1_X] #30914
Conversation
A new Pull Request was created by @dildick (Sven Dildick) for CMSSW_11_1_X. It involves the following packages: DataFormats/CSCDigi @cmsbuild, @rekovic, @benkrikler, @civanch, @mdhildreth 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 |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
Interesting. I just tested this branch in CMSSW_11_1_X_2020-07-25-1100 on a 11_1_0_pre8 relval sample (in particular The number of wiregroups the pretrigger loops on is constrained to [0,47]. Somehow the wiregroup number starts inflating past the bounds of the for-loop, ultimately causing a segfault in the anode processor pretrigger function.
Not sure what is causing this. The anode pretrigger function did not change recently. I also did not see such weird behavior in the corresponding 11_2_X branch (#30909). In fact, I don't recall ever seeing this. It seems that - at the very least - I need to add another explicit check that the wiregroup in the for-loop is valid. |
I noticed that |
@rekovic ? |
Hi Sven,
As I am sure you're aware, all offline geometry counts from 1, so the
maximum number of wiregroups in ME1/1 is 48 and counts 1-48.
If you want to make a statement like 'wiregroup numbering starts from 0'
please make sure it is emphasized that this is in the trigger code only.
Otherwise non-experts will get very confused.
Regards, Tim
… Sven Dildick ***@***.***>
July 27, 2020 at 01:43
I noticed that |if (lct.getKeyWG() > max_wire)| in |checkValid| should
be tightened to |if (lct.getKeyWG() >= max_wire)|. E.g. max_wire
returns 48 for ME1/1, but wiregroup numbering starts from 0.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#30914 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABGYLHTV74E23P2P4LUJS7TR5S5Q7ANCNFSM4PHOZ6AA>.
|
hi @dildick Why would you not see this in 11_2_X is surprising to me. Is there anything in the geometry and counting that is different b/w 11_1_X and 11_2_X (@civanch @ptcox) ? [1] |
@rekovic I'll check it now on an HLT TDR sample. |
Pull request #30914 was updated. @cmsbuild, @rekovic, @benkrikler, @civanch, @mdhildreth can you please check and sign again. |
Efficiencies largely above 90%. Outliers are (1) ME1/2, which does not have upgraded processors or motherboard algorithms, (2) ME2/1 near |eta|~1.7. Despite loosening matching windows in GE2/1, I'm not yet able to recover this inefficiency. Requires more investigation. |
@tahuang1991 Any idea why the GE2/1-ME2/1 algorithm would loose 20% efficiency near |eta|~1.7? |
please test |
The tests are being triggered in jenkins.
|
unhold |
@dildick thank you very much for the plots I admit I am not familiar with them... do you have them before the fix ? |
@dildick Do you have any plots of change in CSC eta-phi coordinates before your work on the updating the algorithms and now ? |
+1 |
Comparison job queued. |
urgent |
Comparison is ready Comparison Summary:
|
merge |
PR description:
An inefficiency was reported in HLT_L1SingleMu25 in CMSSW_11_2_0_pre2, which was not present in CMSSW_11_2_0_pre1 (https://its.cern.ch/jira/browse/CMSLITDPG-903). Investigation showed only ME1/2 LCTs (oddly enough) with invalid pattern numbers. This was fixed with 9354dff.
Further investigation revealed that the CLCT processor readout function was not checking if CLCTs were valid, and that GEM-CSC motherboards do not check if incoming pads are valid. The code was also missing quality control. I added a number of
checkValid
functions that check the properties for ALCT/CLCT/LCT at various stages of the algorithm. LogErrors are printed in case values go out of bounds.PR validation:
Tested on 10k events of
/RelValSingleMuFlatPt2To100/CMSSW_11_0_0-PU25ns_110X_mcRun4_realistic_v3_2026D49PU200-v1/GEN-SIM-DIGI-RAW
/RelValSingleMuFlatPt2To100/CMSSW_11_0_0-110X_mcRun4_realistic_v2_2026D49noPU-v1/GEN-SIM-DIGI-RAW
I did not see LogErrors of invalid stubs.
if this PR is a backport please specify the original PR and why you need to backport that PR:
Backport of #30909.