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
81x L1T for HI run - tower-counting algorithm (no new CondFormats) #16324
81x L1T for HI run - tower-counting algorithm (no new CondFormats) #16324
Conversation
Conflicts: EventFilter/L1TRawToDigi/src/implementations_stage2/CaloSetup.cc L1Trigger/L1TGlobal/data L1Trigger/L1TMuon/data
…BypassEGVetos_ and jetBypassPUS_ are currently always used and configured as false). This avoids any needs for new Global Tag.
please test |
The tests are being triggered in jenkins. |
A new Pull Request was created by @rekovic for CMSSW_8_1_X. It involves the following packages: CondFormats/L1TObjects @ghellwig, @cerminar, @cmsbuild, @rekovic, @franzoni, @ggovi, @mmusich, @mulhearn, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here #13028 |
…ibly avoid unnecessary signatures.
please test |
The tests are being triggered in jenkins. |
@@ -24,6 +24,7 @@ enum GlobalObject | |||
gtHTT, | |||
gtHTM, | |||
gtETMHF, | |||
gtTowerCount, |
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.
isn't inserting in the middle of an enum breaking the backward compatibility?
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.
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.
nothing appears to depend on how many enums of this type there are - so seems ok to me.
Comparison job queued. |
+1 |
This pull request is fully signed and it will be integrated in one of the next CMSSW_8_1_X IBs (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @slava77, @davidlange6, @smuzaffar |
Comparison job queued. |
|
||
//HI-SUM | ||
|
||
l1t::EtSum towCount = l1t::EtSum(); |
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.
@rekovic i guess we can have "raw" data around without this new piece of information? Or is that not possible? If so, some protection is needed when the new information is not present.
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.
Yes. All the previous data do not have kTowerCount types in EtSum. The unpacker will then assign "0" Pt to TowerCount sums in those cases. Same as before, when we added new EtSum types.
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.
ok, so the data are 0 padded (as opposed to reading off the end of a data structure
if (iEt<=0) continue; | ||
|
||
// if tower Et is saturated, saturate jet Et | ||
if (seedEt >= 511) iEt = 65535; | ||
if (seedEt >= 509) iEt = 65535; |
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.
what does "509" correspond to? (511 was somehow understandable as 2^9-1)
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.
From the Layer2 firmware experts:
now saturate at seed Et = 509, 510 as well as 511 (saturation codes)
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.
Thanks @rekovic - please add a comment for the back port of this
+1 |
Is this object written? In which data tiers? Il 24 ott 2016 10:13 AM, "rekovic" notifications@github.com ha scritto:
|
@arizzi No, it is not. |
This is 81x PR. Corresponding 80x PR is #16323.
This is a PR analogous to #16320, but removing the two new data members (bools egBypassEGVetos_ and jetBypassPUS_ ) in CondFormats, which are currently always used, set and configured, as false.
This avoids any need for a new GlobalTag.
Description:
This is a 80X PR for tower-counting algorithm at L1T needed for pPb run.
Book-keeping note: This is a slim-down and squashed commits addendum derived from l1t-integration-v88.0_CMSSW_8_0_21 (which contains TowrCounting for Layer2) plus uGT development.