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

Run-3 ALCT and LCT data formats #29456

Merged
merged 16 commits into from
May 6, 2020
Merged

Run-3 ALCT and LCT data formats #29456

merged 16 commits into from
May 6, 2020

Conversation

dildick
Copy link
Contributor

@dildick dildick commented Apr 10, 2020

PR description:

This PR extends the ALCT and LCT data formats for Run-3. Detailed information can be found in this note: https://gitlab.cern.ch/tdr/notes/DN-20-016/blob/master/temp/DN-20-016_temp.pdf

Edited Summary:

ALCT changes (section 3.1 in DN-20-016)

  • 3 highest bits in BXN[4:0], BXN[4:2], will be reassigned for high-multiplicity triggering
  • a new high-multiplicity trigger member hmt_ was added
  • a new member version_ that indicates Run3 or Legacy was added

CLCT changes

  • a new member version_ that indicates Run3 or Legacy was added

LCT changes (section 3.2 in DN-20-016)

  • 2 bits are reallocated to encode the 1/4 and 1/8 strip bit (see also Run-3 CLCT and LCT data formats (CCLUT-3) #29205 )
  • 4-bit quality becomes a 3-bit for ME1/1, or 2-bit for non-ME1/1
  • 4-bit pattern ID is reinterpreted as 4-bit bending value
  • 2-bit (3-bit) high-multiplicity trigger word for each ME1/1 (non-ME1/1) chamber
  • a new high-multiplicity trigger member hmt was added
  • a new member version_ that indicates Run3 or Legacy was added

PR validation:

Tested with WF 22034.0

if this PR is a backport please specify the original PR and why you need to backport that PR:

N/A

@cmsbuild
Copy link
Contributor

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-29456/14646

  • This PR adds an extra 24KB to repository

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @dildick (Sven Dildick) for master.

It involves the following packages:

DataFormats/CSCDigi
DataFormats/L1CSCTrackFinder

@cmsbuild, @rekovic, @benkrikler, @civanch, @mdhildreth can you please review it and eventually sign? Thanks.
@ptcox, @rovere this is something you requested to watch as well.
@silviodonato, @dpiparo you are the release manager for this.

cms-bot commands are listed here

@dildick
Copy link
Contributor Author

dildick commented Apr 10, 2020

@civanch I think I still need to add a member in order to distinguish Run-1/2 from Run-3 ALCTs and LCTs. I was able to do this for CLCTs in #29205 with the comparator code value. For ALCTs and LCTs, there is no obvious choice with the existing members. Some CSC folks suggested to add a flag isRun3. Can you offer a recommendation?

@civanch
Copy link
Contributor

civanch commented Apr 12, 2020

please test

@cmsbuild
Copy link
Contributor

cmsbuild commented Apr 12, 2020

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/5670/console Started: 2020/04/12 17:52

@civanch
Copy link
Contributor

civanch commented Apr 12, 2020

@dildick , addition of an extra flag seems to be a working solution. However, it is not the first case when in a sub-detector we have to modify data structure, let us discuss with experts what is optimal in the case of a minor change as you have.

@cmsbuild
Copy link
Contributor

+1
Tested at: af35b55
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-4c06e6/5670/summary.html
CMSSW: CMSSW_11_1_X_2020-04-12-0000
SCRAM_ARCH: slc7_amd64_gcc820

@cmsbuild
Copy link
Contributor

Comparison job queued.

@cmsbuild
Copy link
Contributor

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-4c06e6/5670/summary.html

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 0 differences found in the comparisons
  • DQMHistoTests: Total files compared: 34
  • DQMHistoTests: Total histograms compared: 2695166
  • DQMHistoTests: Total failures: 21
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 2694826
  • DQMHistoTests: Total skipped: 319
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 33 files compared)
  • Checked 147 log files, 16 edm output root files, 34 DQM output files

@dildick
Copy link
Contributor Author

dildick commented Apr 13, 2020

@silviodonato Do you have a suggestion I can implement?

@civanch
Copy link
Contributor

civanch commented Apr 14, 2020

@makortel , @bsunanda , can you, please, comment what is optimal solution for a producer if data format slightly changed for Run-3?

@dildick
Copy link
Contributor Author

dildick commented Apr 17, 2020

Glad to see that the unit test passed this time. Other than that, the comparisons look good; no failures in the CSC system that I can tell.

@@ -81,7 +84,7 @@ void CSCCLCTDigi::clear() {
}
}

int CSCCLCTDigi::getKeyStrip(int n) const {
uint16_t CSCCLCTDigi::getKeyStrip(const uint16_t n) const {
// 10-bit case for strip data word
if (compCode_ != -1 and n == 8) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This is for Run 3 only, I guess? Just to confirm: the "compCode" has never been used in Run 2, i.e. it was unused in firmware, and was always set to -1 in software? (See getCompCode() function above.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, correct. I suppose we can update this function so that for Run-1/2 it always returns the half-strip, whatever the argument.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think that's already what it does, no? See below, "// 8-bit case for strip data word (all other cases)"

Copy link
Contributor Author

@dildick dildick Apr 17, 2020

Choose a reason for hiding this comment

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

Yes, it does.

@abrinke1
Copy link
Contributor

abrinke1 commented Apr 17, 2020 via email

@dildick
Copy link
Contributor Author

dildick commented Apr 21, 2020

Hi, are there more comments on this PR?

@perrotta
Copy link
Contributor

+1

  • Reconstruction code is only marginally touched by this PR: minor reco changes in EventFilter/CSCRawToDigi/src/CSCDigiToRaw.cc, justified by the change from int to uint16_t in the return value of two functions defined elsewhere
  • Jenkins tests pass and show no differences in reco outputs

@civanch
Copy link
Contributor

civanch commented Apr 24, 2020

+1

@silviodonato
Copy link
Contributor

@rekovic do you have any comments?

@dildick
Copy link
Contributor Author

dildick commented May 1, 2020

Hi, can this PR be integrated?

@silviodonato
Copy link
Contributor

Reminder @rekovic (CMSSW_11_1_0_pre7 is scheduled for tomorrow)

@rekovic
Copy link
Contributor

rekovic commented May 6, 2020

@dildick
Please make a follow-up PR with changing the name of getter function to follow the naming rules 2.11 (http://cms-sw.github.io/cms_coding_rules.html)

+1

@rekovic
Copy link
Contributor

rekovic commented May 6, 2020

+1

@cmsbuild
Copy link
Contributor

cmsbuild commented May 6, 2020

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. @silviodonato, @dpiparo (and backports should be raised in the release meeting by the corresponding L2)

@silviodonato
Copy link
Contributor

+1

@cmsbuild cmsbuild merged commit 97be8ff into cms-sw:master May 6, 2020
@dildick dildick deleted the from-CMSSW_11_1_X_2020-04-08-1100-run3-dataformats branch May 7, 2020 00:07
@dildick
Copy link
Contributor Author

dildick commented May 7, 2020

@rekovic I see. I'll need to remove the "get" from each getter function... Is there a chance this introduces an issue with reading old MC/data with newer code?

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.