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
[L1T] Phase-2, correlator developments #39397
Conversation
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-39397/32102
|
A new Pull Request was created by @cecilecaillol for master. It involves the following packages:
@rekovic, @epalencia, @cmsbuild, @AdrianoDee, @srimanob, @cecilecaillol can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-faae7c/27563/summary.html Comparison SummarySummary:
|
+l1 |
urgent |
process.source = cms.Source("PoolSource", | ||
fileNames = cms.untracked.vstring('file:inputs110X.root'), | ||
inputCommands = cms.untracked.vstring("keep *", | ||
"drop l1tPFClusters_*_*_*", |
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.
Is this correct, not *_l1tPFClusters_*_*
? I assume l1tPFClusters
is a module name, not type.
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.
@@ -5,12 +5,10 @@ | |||
#include <vector> | |||
|
|||
#include "DataFormats/L1TParticleFlow/interface/layer1_emulator.h" | |||
#include "L1Trigger/Phase2L1ParticleFlow/interface/dbgPrintf.h" | |||
|
|||
#ifdef CMSSW_GIT_HASH |
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.
Just my curiosity, why do we need CMSSW_GIT_HASH
to control ParameterSet
header file? I search on CMSSW git, I see only L1T uses this style.
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.
@gpetruc Can you address this question?
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.
Because I also need to compile the same files from outside CMSSW within Vivado when compiling the IP cores for the firmware.
@@ -53,10 +53,10 @@ void l1ct::multififo_regionizer::RegionBuffer<T>::initFifos(unsigned int nfifos) | |||
for (auto& t : queues_.back().second) | |||
t.clear(); | |||
} | |||
if (!(nfifos == 1 || nfifos == 2 || nfifos == 4 || nfifos == 6 || nfifos == 8 || nfifos == 12)) { | |||
if (!(nfifos == 1 || nfifos == 2 || nfifos == 3 || nfifos == 4 || nfifos == 6 || nfifos == 8 || nfifos == 12)) { |
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.
Very minor. give this is used twice could be worth to define bool isGood = (nfifos == 1 || nfifos == 2 || nfifos == 3 || nfifos == 4 || nfifos == 6 || nfifos == 8 || nfifos == 12);
and the use the assert
as assert(isGood);
.
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.
Done
@@ -76,6 +77,8 @@ class L1TCorrelatorLayer1Producer : public edm::stream::EDProducer<> { | |||
const std::string regionDumpName_; | |||
bool writeRawHgcalCluster_; | |||
std::fstream fRegionDump_; | |||
std::vector<edm::ParameterSet> patternWriterConfigs_; |
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.
const
?
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.
Done
const unsigned int tfTimeslices_ = 3, tfLinksFactor_ = 1; // not really configurable in current architecture | ||
const unsigned int hgcTimeslices_ = 3, hgcLinksFactor_ = 4; // not really configurable in current architecture | ||
const unsigned int gctTimeslices_ = 1, gctSectors_ = 3; // not really configurable in current architecture | ||
const unsigned int gctLinksEcal_ = 1, gctLinksHad_ = 2; // could be made configurable later | ||
const unsigned int gmtTimeslices_ = 3, gmtLinksFactor_ = 1; // not really configurable in current architecture | ||
const unsigned int gttTimeslices_ = 1, gttLinksFactor_ = 1; // not really configurable in current architecture |
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.
Could be constexpr
s.
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.
non-static data member cannot be 'constexpr', were you suggesting a more complex change than just switching const to constepr?
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.
Sorry no, I had missed that, not intended to add complexity
enum class Partition { Barrel, HGCal, HGCalNoTk, HF }; | ||
|
||
Partition partition_; | ||
const unsigned int tmuxFactor_ = 6; // not really configurable in current architecture |
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.
Could be constexpr
.
outputBoard_(-1), | ||
outputLinkEgamma_(-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.
Do you actually want these to be always constant? If so I would move their initialization to the class header (and put them as constexpr
). If not and you want to have a default value, a fillDescription
may be added to the class. You can do it starting from a an existing cfi
file and following this.
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.
@gpetruc Can you comment?
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.
No, they're not always constant, they're filled later in the constructor depending on which detector region is implemented.
A fillDescriptions could be written, but as you can see from the code below in the constructor it will end end up probably being pretty complex as the set of parameters needed depends on the values of the parameters.
L1TCorrelatorLayer1PatternFileWriter::L1TCorrelatorLayer1PatternFileWriter(const edm::ParameterSet& iConfig, | ||
const l1ct::Event& eventTemplate) | ||
: partition_(parsePartition(iConfig.getParameter<std::string>("partition"))), | ||
writeInputs_(iConfig.existsAs<std::string>("inputFileName") && |
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.
These iConfig.existsAs
could be avoided with a fillDescription()
. I would change them adding two input parameters (such as writeInputs
and writeOutputs
) to actually turn these features on, rather than relying on some other parameter.
Having a lot of parameters that used conditionally you would simply need to fill them with dummy values when they are not actually used.
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.
I do prefer to not have the parameter at all when it's not used, instead of having it filled with dummy values, so that whenever one enables something that requires those parameters but fails to specify them, the code fails cleanly with a 'missing parameter' error (instead of having to rely on the code to check whether the parameter values are dummy or not, which isn't always obvious)
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.
Hmm, that will not wash with ConfDB: the top-level parameters of a plugin are treated fixed, and one can not have additional/different parameters depending on the value of some other parameter.
Does this ever need to run as part of the L1T emulator of phase-2 within HLT?
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.
This class is only used to produce text files dumps of L1T data to use in board tests - something that one would never want to run in production or in HLT
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!
(cherry picked from commit f51be45)
Pull request #39397 was updated. @rekovic, @epalencia, @cmsbuild, @AdrianoDee, @srimanob, @cecilecaillol can you please check and sign again. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-39397/32281
|
Pull request #39397 was updated. @rekovic, @epalencia, @cmsbuild, @AdrianoDee, @srimanob, @cecilecaillol can you please check and sign again. |
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-faae7c/27811/summary.html Comparison SummarySummary:
|
+upgrade
|
+l1 |
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. @perrotta, @dpiparo, @rappoccio (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
This PR includes the latest devlopments to the Phase-2 L1 correlator. The local PR is cms-l1t-offline#1031
We would like this PR to be backported to 12_5 for our Phase-2 MC production
PR validation:
code-checks, code-format, objects validated in our local branch