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
CTPPS: bug fix in run ranges for FEDs channels mapping #18461
Conversation
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. 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"), |
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.
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.
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.
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
...
…the VFAT frames unpacking
Commit bbc0068 fixes this unexpected behaviour when first event number observed is 0 instead of 1. |
type bugfix |
@cmsbuild please test @forthommel please make a PR for 91X to follow the regular policy of changes |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
if (startEventID == EventID(1, 0, 1)) | ||
startEventID = EventID(1, 0, 0); | ||
if (startEventID.event() == 1) | ||
startEventID = EventID(startEventID.run(), startEventID.luminosityBlock(), 0); |
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 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)
+1 |
+1 |
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 |
Hi @davidlange6 Let me know whenever I can forward-port this fix onto the |
if you've confirmed that this can now process 280385, then indeed, we need the usual master branch (and probably 91x) pull requests
… On May 15, 2017, at 11:16 AM, Laurent Forthomme ***@***.***> wrote:
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Indeed, I am now successfully processing this run with the PSet configuration attached to the HN thread you quoted (currently at event 210). |
This PR modifies the run ranges parser to account for scenarios where the first event number in a run is
0
instead of1
, 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 yielded9 9 8 6 4 1 1 1 tests passed, 1 0 0 0 0 0 0 0 failed
(again,DAS_ERROR
on4.22
)