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

CTPPS: bug fix in run ranges for FEDs channels mapping #18461

Merged

Conversation

forthommel
Copy link
Contributor

@forthommel forthommel commented Apr 25, 2017

This PR modifies the run ranges parser to account for scenarios where the first event number in a run is 0 instead of 1, thus preventing any channels mapping to be defined for this event.
It hence allows runs at the edge of these ranges to properly retrieve a channels mapping for both the strips and diamond detectors.
It also backports a bug fix raised in #18283 (comment) by @perrotta preventing the CRC check to be performed on the VFAT frame is the unpacker verbosity is set to 0.

runTheMatrix -l limited on bbc0068 yielded 9 9 8 6 4 1 1 1 tests passed, 1 0 0 0 0 0 0 0 failed (again, DAS_ERROR on 4.22)

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @forthommel (Laurent Forthomme) for CMSSW_8_0_X.

It involves the following packages:

EventFilter/CTPPSRawToDigi

@perrotta, @cmsbuild, @slava77, @davidlange6 can you please review it and eventually sign? Thanks.
@Martin-Grunewald this is something you requested to watch as well.
@davidlange6, @smuzaffar you are the release manager for this.

cms-bot commands are listed here #13028

mappingFileNames = cms.vstring(),
maskFileNames = cms.vstring()
),
# after TS2 (2016)
cms.PSet(
validityRange = cms.EventRange("281601:min - 999999999:max"),
validityRange = cms.EventRange("281600:min - 999999999:max"),
Copy link
Contributor

Choose a reason for hiding this comment

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

Now I'm missing how this code works: the previous range ends at 281600:max, while this range starts at 281600:min, which at least semantically suggests there is an overlap.
Please explain why there is no overlap and see if it's possible to remove it even in config semantics.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi @slava77
It seems that the bug lies further away than this, as the first event in /store/data/Run2016H/ZeroBias/RAW/v1/000/283/820/00000/462D2A5B-B19A-E611-B100-02163E01382E.root' (as discussed offline) is 283820:0:0, while 283820:min seems to correspond to 283820:0:1...

@cmsbuild
Copy link
Contributor

Pull request #18461 was updated. @perrotta, @ghellwig, @arunhep, @cerminar, @cmsbuild, @franzoni, @slava77, @ggovi, @mmusich, @davidlange6 can you please check and sign again.

@forthommel
Copy link
Contributor Author

Commit bbc0068 fixes this unexpected behaviour when first event number observed is 0 instead of 1.

@forthommel forthommel changed the title CTPPS: modified run ranges for FEDs channels mapping CTPPS: bug fix in run ranges for FEDs channels mapping Apr 25, 2017
@forthommel
Copy link
Contributor Author

type bugfix

@slava77
Copy link
Contributor

slava77 commented Apr 25, 2017

@cmsbuild please test

@forthommel please make a PR for 91X to follow the regular policy of changes

@cmsbuild
Copy link
Contributor

cmsbuild commented Apr 25, 2017

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/19382/console Started: 2017/04/25 15:55

@cmsbuild
Copy link
Contributor

@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-18461/19382/summary.html

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 0 differences found in the comparisons
  • DQMHistoTests: Total files compared: 16
  • DQMHistoTests: Total histograms compared: 1164335
  • DQMHistoTests: Total failures: 1176
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 1163041
  • DQMHistoTests: Total skipped: 118
  • DQMHistoTests: Total Missing objects: 0
  • Checked 63 log files, 14 edm output root files, 16 DQM output files

if (startEventID == EventID(1, 0, 1))
startEventID = EventID(1, 0, 0);
if (startEventID.event() == 1)
startEventID = EventID(startEventID.run(), startEventID.luminosityBlock(), 0);
Copy link
Contributor

Choose a reason for hiding this comment

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

I suspect that "1" in "1:min" was not special and the comment should be
// event id "N:min" has a special meaning and is translated to a truly minimal event id (N:0:0)
We have clearly discovered in MC that the first call is made not inside an event but inside a beginRun transition to make this comment for MC. This PR is apparently the first time we tried this code on the transition run.

If you look in the job failing in 283820 the file first entry is the run transition

         283820              0              0              0 (Run)

@perrotta
Copy link
Contributor

+1
Tested in CMSSW_8_0_27 with the same input file where the crash was experienced:
/store/data/Run2016H/ZeroBias/RAW/v1/000/283/820/00000/462D2A5B-B19A-E611-B100-02163E01382E.root
this PR actually fixes it.

@arunhep
Copy link
Contributor

arunhep commented Apr 26, 2017

+1

@davidlange6 davidlange6 merged commit 897c137 into cms-sw:CMSSW_8_0_X Apr 27, 2017
@davidlange6
Copy link
Contributor

hi @forthommel looks like we failed to notice that this PR still does not handle begin/end conditions correctly. The code presumably was written for run ranges rather than the more complicated EventRanges and the evolution is still not complete.

Please change to use the contains function defined in the EventRange header (its not clear to me why there is no contains method of the class it self but there is not..)

See:

https://hypernews.cern.ch/HyperNews/CMS/get/prep-ops/3940/1/1/1/1/1.html

@forthommel
Copy link
Contributor Author

Hi @davidlange6
As shown above, another bug fix has been submitted for reviewing in 8_0_X (#18732). It implements your suggestion of replacing our home-made run ranges check with the centrally-provided edm::contains method.

Let me know whenever I can forward-port this fix onto the master branch.

@davidlange6
Copy link
Contributor

davidlange6 commented May 15, 2017 via email

@forthommel
Copy link
Contributor Author

Indeed, I am now successfully processing this run with the PSet configuration attached to the HN thread you quoted (currently at event 210).
I will then launch the forward-port(s).

@forthommel forthommel deleted the ctpps-runranges_channels_patch-8_0_X branch July 17, 2017 13:05
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.

None yet

6 participants