Skip to content
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

uGT fix for muon showers full emulation and for HMT mismatches in the DQM workflow #40773

Merged
merged 5 commits into from
Feb 24, 2023

Conversation

elfontan
Copy link
Contributor

@elfontan elfontan commented Feb 15, 2023

PR description:

The purpose of this PR is to address multiple issues at the GT level related to the muon shower emulation. Here two main items are discussed:

  1. uGT emulation of HMT
  2. DQM mismatches

Thanks @eyigitba and @aloeliger for the work and the discussion.

  1. uGT emulation of HMT
    The MuonShowerCondition class was broken and was not evaluating at all the condition: this PR contains a first iteration of updates to get reasonable results (with a proper check of the condition for all HMT cases, able to distinguish between Nominal and Tight showers).

Summary of the main issues:

  • The checkObjectParameter function responsible for the check of the muon shower bit for each condition was never called in the class.
  • The vector of candidates in MuonShowerCondition (int numberObjects = candVec->size(useBx)) was returning four objects (as supposed to be given the splitting in four separate muon shower objects in the Global Board), but we never compare them one by one to the MuonShowerTemplate. For each condition, we should compare each object to the template to make sure one of them passes. All four objects are exclusive in which bits are set to true.
  • The declaration of the four muon shower objects in the GlobalBoard was wrong: without having them declared as pointers, they were not passed correctly to the MuonShowerCondition (that was receiving random objects).

Open items:

  • At the moment, the class is checking only the central BX: ReceiveMuonShowerObjectData is only looking at BX0. However, we can have showers in other BXs, too (as we saw last year with muon showers before fixing the timing). This has to be included.
  • Github issue in the OSW IB: BX Checking for Muon Showers cms-l1t-offline/cmssw#1071.
  • In the L1Ntuple workflow running on 1000 events using run 362720 (find the cmsDriver command below), two additional events with a nominal shower were found, and five of those events fire for a tight shower (when we would expect a nominal shower only). No mismatch when running the DQM with the below fix.
    Note that L1Ntuple workflow runs the full L1 emulation starting from muonCSCDigis, so the steps in the middle that might be responsible for the discrepancy are: CSC digi unpacker, CSC shower re-emulation, EMTF shower re-emulation.
    After a follow up with @kakwok, we realised that the new CSC thresholds for the HMT shower thresholds had not been updated after the deployment online: fix in Update HMT shower thresholds for HMT emulation in CSC #40829. Including this fix, a single event with a mismatch is found (having both a Nominal and Tight shower): 362720:105:115847543.
    Further checks with @eyigitba for EMTF and @kakwok for CSC needed.
    Github issue in the OSW IB: Muon Shower Emulator Mismatch cms-l1t-offline/cmssw#1070.

Validation:

  • L1 emulation run using the L1Ntuples worflow and checking the number of events triggered by HMT. Expected number of events in data: 12 L1_SingleMuShower_Nominal and 5 L1_SingleMuShower_Tight; current emulator counts: 13 L1_SingleMuShower_Nominal and 6 L1_SingleMuShower_Tight.
  • The testing cmsDriver command is:
    cmsDriver.py l1Ntuple -s RAW2DIGI --python_filename=data.py -n 1000 --era=Run3 --data --conditions=126X_dataRun3_Prompt_v2 --customise=L1Trigger/L1TNtuples/customiseL1Ntuple.L1NtupleRAWEMU --customise=L1Trigger/Configuration/customiseReEmul.L1TReEmulFromRAW --filein=/store/data/Run2022G/EphemeralHLTPhysics0/RAW/v1/000/362/720/00000/36f350d4-8e8a-4e38-b399-77ad9bf351dc.root --nThreads 8
  1. DQM mismatches (countings in data, zero countings in the emulator)
  • Strategy: Running the emulator with the DQM workflow (see instructions) for a specific run containing showers (run 362720).
  • Missing input for the hadronic showers in valGtStage2Digis: to be added here.
  • At the beginning, providing the uGT input coming from the unpacker, MuonInputTag = "gtStage2Digis:MuonShower", we still observed zero countings; switching to the GMT output MuonInputTag = "gmtStage2Digis:MuonShower", the mismatches disappeared. A fix of the GT unpacker for showers was needed: follow up with @dinyar in Fix expected version number of uGT with muon shower support #40822. Everything was tested again with this update and worked successfully (no dataVSemu mismatches in the DQM).

NOTE: An update of the script to produce test vectors for the uGT firmware-emulator comparison is also provided to rely on the unpacked uGT information as input for the muon shower objects.

PR validation:

Basic tests performed successfully starting from CMSSW_13_0_0_pre4

cmsrel CMSSW_13_0_0_pre4
cd CMSSW_13_0_0_pre4/src
cmsenv
git cms-addpkg L1Trigger/L1TGlobal
git cms-addpkg DQM/L1TMonitor
scram b distclean
git cms-checkdeps -a -A
scram b -j 8
scram b runtests
scram build code-checks
scram build code-format

@cmsbuild
Copy link
Contributor

-code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-40773/34199

  • This PR adds an extra 28KB to repository

Code check has found code style and quality issues which could be resolved by applying following patch(s)

@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-40773/34200

  • This PR adds an extra 28KB to repository

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @elfontan (Elisa Fontanesi) for master.

It involves the following packages:

  • DQM/L1TMonitor (dqm)
  • L1Trigger/L1TGlobal (l1)

@epalencia, @emanueleusai, @cmsbuild, @rekovic, @syuvivida, @pmandrik, @micsucmed, @cecilecaillol, @rvenditti can you please review it and eventually sign? Thanks.
@Martin-Grunewald, @missirol this is something you requested to watch as well.
@perrotta, @dpiparo, @rappoccio you are the release manager for this.

cms-bot commands are listed here

Comment on lines 388 to 402
l1t::MuonShower* musOneNominalInTime = new l1t::MuonShower(false, false, false, false, false, false);
l1t::MuonShower* musOneTightInTime = new l1t::MuonShower(false, false, false, false, false, false);
l1t::MuonShower* musOutOfTime0 = new l1t::MuonShower(false, false, false, false, false, false);
l1t::MuonShower* musOutOfTime1 = new l1t::MuonShower(false, false, false, false, false, false);

musOneNominalInTime->setOneNominalInTime(mu->isOneNominalInTime());
musOneTightInTime->setOneTightInTime(mu->isOneTightInTime());
musOutOfTime0->setMusOutOfTime0(mu->musOutOfTime0());
musOutOfTime1->setMusOutOfTime1(mu->musOutOfTime1());

(*m_candL1MuShower).push_back(0, &(*musOneNominalInTime));
(*m_candL1MuShower).push_back(0, &(*musOneTightInTime));
(*m_candL1MuShower).push_back(0, &(*musOutOfTime0));
(*m_candL1MuShower).push_back(0, &(*musOutOfTime1));

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume that using a std::unique_ptr is not possible here because of the .h function interface here?

inline const BXVector<const l1t::MuonShower*>* getCandL1MuShower() const { return m_candL1MuShower; }

If it is, I think that might be better, because I am concerned that the allocated musOneNominalInTime, musOneTightInTime,musOutOfTime0, & musOutOfTime1 may be leaking memory. They are put into the BXVector m_candL1MuShower but I don't see anything that explicitly de-allocates this allocated memory, and I don't see anything inside the BXVector code that would do it either.

Later clear is called here:

m_candL1MuShower->clear();

but this more or less boils down to calling a std::vector.clear() I think, which may call destructors, but is not equivalent to delete on the objects to the best of my knowledge. There is also BX range setting here:

m_candL1MuShower->setBXRange(m_bxFirst_, m_bxLast_);

But I don't think that has an effect if the BX numbers are the same as before, (isn't -2,-1,0,1,2 pretty typical for a BX vector?)

void BXVector<T>::setBXRange(int bxFirst, int bxLast) {
int bxF = bxFirst_;
int bxL = bxLast_;
if (bxFirst < bxFirst_) {
for (int i = 0; i < bxF - bxFirst; i++) {
itrs_.insert(itrs_.begin(), itrs_[0]);
}
}
if (bxFirst > bxFirst_) {
for (int i = 0; i < bxFirst - bxF; i++) {
deleteBX(bxF + i);
}
}
if (bxLast > bxLast_) {
for (int i = 0; i < bxLast - bxL; i++) {
addBX();
}
}
if (bxLast < bxLast_) {
for (int i = 0; i < bxL - bxLast; i++) {
deleteBX(bxL - i);
}
}
bxFirst_ = bxFirst;
bxLast_ = bxLast;
}

Perhaps I am missing something though. Is there something I am not seeing that makes sure that the memory allocated for musOneNominalInTime, musOneTightInTime,musOutOfTime0, and musOutOfTime1 is later de-allocated?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @aloeliger , these changes were mostly done by me rather quickly. I didn't try using std::unique_ptr. This is only one possible fix to this issue. Anybody who is more of an expert on uGT emulator should look into this to see if there are more efficient solutions. I'm also not a huge fan of splitting one object to four objects which creates this problem to begin with. Other uGT objects are just pushed back to the vector just by their iterator.

@epalencia
Copy link
Contributor

Please test

@cmsbuild
Copy link
Contributor

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-87b664/30674/summary.html
COMMIT: 29ecd54
CMSSW: CMSSW_13_1_X_2023-02-16-1100/el8_amd64_gcc11
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/40773/30674/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

  • You potentially added 16 lines to the logs
  • Reco comparison results: 13 differences found in the comparisons
  • DQMHistoTests: Total files compared: 49
  • DQMHistoTests: Total histograms compared: 3556272
  • DQMHistoTests: Total failures: 12
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 3556238
  • DQMHistoTests: Total skipped: 22
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 48 files compared)
  • Checked 213 log files, 164 edm output root files, 49 DQM output files
  • TriggerResults: no differences found

@dinyar
Copy link
Contributor

dinyar commented Feb 20, 2023

Hi @elfontan,

I've put the fix of the uGT unpacker in #40822. Can you check if it works when run together with your changes? Once it's ok I can also create backports. (I assume to 13_0_X and 13_1_X?)

Cheers,
Dinyar

@@ -130,6 +130,7 @@
valGtStage2Digis = simGtStage2Digis.clone(
ExtInputTag = "gtStage2Digis",
MuonInputTag = "gtStage2Digis:Muon",
MuonShowerInputTag = "gmtStage2Digis:MuonShower",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once #40822 is confirmed working and merged I think one should use the gt digis here, right?

@elfontan
Copy link
Contributor Author

Thanks so much @dinyar! Sure, I am going to finalize some updates today/tomorrow and I will test your fix together with this PR, and update the MuonShowerInputTag in DQM/L1TMonitor/python/L1TStage2Emulator_cff.py before moving this one to Ready for review.

@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-40773/34326

  • This PR adds an extra 40KB to repository

@cmsbuild
Copy link
Contributor

Pull request #40773 was updated. @aloeliger, @epalencia, @emanueleusai, @cmsbuild, @syuvivida, @pmandrik, @micsucmed, @cecilecaillol, @rvenditti can you please check and sign again.

@elfontan elfontan changed the title uGT fix for muon showers and temporary fix in the DQM workflow for HMT mismatches uGT fix for muon showers full emulation and for HMT mismatches in the DQM workflow Feb 23, 2023
@aloeliger
Copy link
Contributor

please test

@cmsbuild
Copy link
Contributor

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-87b664/30839/summary.html
COMMIT: 4ab1cdb
CMSSW: CMSSW_13_1_X_2023-02-23-1100/el8_amd64_gcc11
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week1/cms-sw/cmssw/40773/30839/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

There are some workflows for which there are errors in the baseline:
22034.911 step 1
The results for the comparisons for these workflows could be incomplete
This means most likely that the IB is having errors in the relvals.The error does NOT come from this pull request

Summary:

  • You potentially added 14 lines to the logs
  • Reco comparison results: 9 differences found in the comparisons
  • DQMHistoTests: Total files compared: 49
  • DQMHistoTests: Total histograms compared: 3528709
  • DQMHistoTests: Total failures: 6
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 3528681
  • DQMHistoTests: Total skipped: 22
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 48 files compared)
  • Checked 213 log files, 164 edm output root files, 49 DQM output files
  • TriggerResults: no differences found

@emanueleusai
Copy link
Member

+1

@emanueleusai
Copy link
Member

type l1t

@cmsbuild cmsbuild added the l1t label Feb 24, 2023
@aloeliger
Copy link
Contributor

+l1

@cmsbuild
Copy link
Contributor

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)

@perrotta
Copy link
Contributor

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants