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

Restore FED error treatment for phase0 (required for UL Rereco of 2016) #26606

Closed

Conversation

veszpv
Copy link
Contributor

@veszpv veszpv commented May 3, 2019

PR description:

The FED raw data format for phase 0 and phase 1 detectors are essentially the same with small differences for the bit-packing of the pixel hit information in layer 1. There is a difference also in the error assignment by the front-end (*). The former case has been treated in the PixelDataFormatter by setting the 'phase1' variable through python configuration files. The error decoding class, called ErrorChecker, however was not made aware of the difference, instead, was just simply updated to phase 1.
This PR fixes that: a base class is defined for the ErrorChecker, the present default code is kept with the same name deriving from this base, and a new derived class ErrorCheckerPhase0 is introduced to restore the phase 0 treatment. The proper error checker is instantiated by the PixelDataFormatter based on the value of 'phase1', so no change needs to be made in the python configurations.

FED error 25: in phase 1, FED error type 25 has been reinterpreted and used by the FED firmware to signal "dead" links. It is used to flag stuck TBMs. This error has a totally different meaning in phase 0. In this PR, the special treatment of this error type by raw-to-digi and digi-to-raw is cancelled for phase 0.

(*) Few error codes have different interpretation; and in phase 0 FPix, the error association with detId is ambiguous.

PR validation:

During the reconstruction of phase 0 data, when a rare type 25 error was encountered, the tracking code crashed. This PR fixes that. The FED25 error packing in simulation, and unpacking in simulation and data for phase 1 should be unchanged, are being validated by @tsusa.

@tsusa @mmusich @dkotlins

veszpv added 6 commits May 2, 2019 15:29
…etector. An empty map results in no FED25 error being packed into the RAW data.
…of phase 0, treatment is reverted to original.
…rit from a virtual base and do some clean-up but leave its phase 1 behavior intact. Create a separate derived class for phase 0 (ErrorCheckerPhase0) restoring the original treatment of a few FED errors and their association to DetId-s.
…rit from a virtual base and do some clean-up but leave its phase 1 behavior intact. Create a separate derived class for phase 0 (ErrorCheckerPhase0) restoring the original treatment of a few FED errors and their association to DetId-s.
…e1 is true (current default), the new phase 0 otherwise.
@cmsbuild
Copy link
Contributor

cmsbuild commented May 3, 2019

The code-checks are being triggered in jenkins.

@@ -252,7 +252,7 @@ void SiPixelRawToDigi::produce( edm::Event& ev,
for (auto const& aPixelError : errorDetSet) {
// For the time being, we extend the error handling functionality with ErrorType 25
// In the future, we should sort out how the usage of tkerrorlist can be generalized
if (aPixelError.getType()==25) {
if (usePhase1==true && aPixelError.getType()==25) {
Copy link
Contributor

Choose a reason for hiding this comment

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

is this even needed on the raw2digi side?
Do we have cases for valid pixel error =25 in phase 0?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In phase 0, error type 25 is exotic but can happen when AFAIK the analog levels in the FED input are not interpreted correctly and the communication protocol is compromised. Such an event was actually caught by reconstruction. So this is indeed needed.

Copy link
Contributor

Choose a reason for hiding this comment

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

Actually this fix is mandatory for full reprocessing of 2016. Without it you will have a small but finite chunk of unprocessable data

@cmsbuild
Copy link
Contributor

cmsbuild commented May 3, 2019

-code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-26606/9549

  • This PR adds an extra 32KB to repository

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

@cmsbuild
Copy link
Contributor

cmsbuild commented May 3, 2019

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

cmsbuild commented May 3, 2019

-code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-26606/9557

  • This PR adds an extra 68KB to repository

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

@perrotta
Copy link
Contributor

perrotta commented May 3, 2019

@veszpv please apply code checks prescription (#26606 (comment)) so that tests can ge started

@cmsbuild
Copy link
Contributor

cmsbuild commented May 3, 2019

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

cmsbuild commented May 3, 2019

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-26606/9567

  • This PR adds an extra 80KB to repository

@cmsbuild
Copy link
Contributor

cmsbuild commented May 3, 2019

A new Pull Request was created by @veszpv (Viktor Veszpremi) for master.

It involves the following packages:

EventFilter/SiPixelRawToDigi

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

cms-bot commands are listed here

@veszpv
Copy link
Contributor Author

veszpv commented May 3, 2019

Note, it seems that "scram build code-format" gives result different from applying the downloaded patch.

The actual changes are quite minimal. 1) Two lines of "if" statements disable the reading/filling of the bad FED channel collection by the (un)packer code, 2) the current ErrorCheck class is made to inherit from a pure virtual base class and the old ErrorCheck from the last phase 0 release (CMSSW_9_3_14_patch1) is copied back as another derived class. Exact same code as used in the last phase 0 reco, only changed to compile in the present release.

@perrotta
Copy link
Contributor

perrotta commented May 3, 2019

please test

@cmsbuild
Copy link
Contributor

cmsbuild commented May 3, 2019

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/34480/console Started: 2019/05/03 17:54

@cmsbuild
Copy link
Contributor

cmsbuild commented May 3, 2019

@cmsbuild
Copy link
Contributor

cmsbuild commented May 3, 2019

Comparison job queued.

@cmsbuild
Copy link
Contributor

cmsbuild commented May 3, 2019

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

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 0 differences found in the comparisons
  • DQMHistoTests: Total files compared: 33
  • DQMHistoTests: Total histograms compared: 3211964
  • DQMHistoTests: Total failures: 78
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 3211682
  • DQMHistoTests: Total skipped: 204
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 32 files compared)
  • Checked 137 log files, 14 edm output root files, 33 DQM output files

Copy link
Contributor

@perrotta perrotta left a comment

Choose a reason for hiding this comment

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

The most awful thing in this PR is the line splitting as it was automatically implemented by the code checks: it makes the code much less easily readable in several parts, besides complicating quite a lot the review by adding tons of unneeded (at best) or worsening changes. In the following review I tried to avoid commenting about those splittings. but it would be nice if they could be reverted here, and their implementation not enforced any more in the clang checks. or at least somehow tuned.


class ErrorCheckerBase {
public:
// typedef unsigned int Word32;
Copy link
Contributor

Choose a reason for hiding this comment

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

Please remove commented out code when not needed

public:
// typedef unsigned int Word32;
// typedef long long Word64;
// typedef unsigned int Word32;
Copy link
Contributor

Choose a reason for hiding this comment

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

Please remove commented out code when not needed


class ErrorCheckerPhase0 : public ErrorCheckerBase {
public:
// typedef unsigned int Word32;
Copy link
Contributor

Choose a reason for hiding this comment

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

Please remove commented out code when not needed


// For the 32bit data format (moved from *.cc namespace, keep uppercase for
// compatibility) Add special layer 1 roc for phase1
int ADC_shift, PXID_shift, DCOL_shift, ROC_shift, LINK_shift, ROW_shift,
Copy link
Contributor

Choose a reason for hiding this comment

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

I really don't like this way of splitting the lines of code.
I understand that this is not you, but rather clang... Let it as such, then.

* tolerances could be given to each input collection.
* Output: FED ids and module detIds that need to be unpacked
* defining the directions of unpacking regions; separate deltaPhi and
* maxZ tolerances could be given to each input collection. Output: FED ids and
Copy link
Contributor

Choose a reason for hiding this comment

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

This should be better fixed and reported to the previous indentation and line splitting, for better readability.
Let profit that checks have been disabled till the closure of pre6 :-)

LogDebug("PixelDataFormatter")
// <<" detId: " << detId
<<print(digi);
// <<" detId: " << detId
Copy link
Contributor

Choose a reason for hiding this comment

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

remove unneeded commented out line

if (fedId < 0)
return fedId;

// if(DANEK) cout<<" digi2raw "<<detId<<" "<<digi.column()<<" "<<digi.row()<<"
Copy link
Contributor

Choose a reason for hiding this comment

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

Please remove these commented out lines if not needed any more

LogDebug("PixelDataFormatter")
// <<" detId: " << detId
<<print(digi);
// <<" detId: " << detId
Copy link
Contributor

Choose a reason for hiding this comment

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

remove


//if(DANEK) cout<<" layer 1: digi2raw "<<detId<<" "<<digi.column()<<" "<<digi.row()<<" "<<digi.adc()<<" "
// <<cabling.link<<" "<<cabling.roc<<" "<<cabling.dcol<<" "<<cabling.pxid<<" "
// if(DANEK) cout<<" layer 1: digi2raw "<<detId<<" "<<digi.column()<<"
Copy link
Contributor

Choose a reason for hiding this comment

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

Please remove these commented out lines if not needed any more

@@ -58,18 +61,16 @@ void PixelUnpackingRegions::run(const edm::Event& e, const edm::EventSetup& es)
edm::Handle<reco::BeamSpot> beamSpot;
e.getByToken(tBeamSpot, beamSpot);
beamSpot_ = beamSpot->position();
//beamSpot_ = math::XYZPoint(0.,0.,0.);
// beamSpot_ = math::XYZPoint(0.,0.,0.);
Copy link
Contributor

Choose a reason for hiding this comment

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

Remove

@veszpv
Copy link
Contributor Author

veszpv commented May 6, 2019

I am not sure how to undo the changes by code check. If you want, I can try to run
git push origin +HEAD
after I removed the commits from my local repo. Would that help? Or I can submit another PR. You are commenting on code that has nothing to do with this PR. Also, I do not think it is feasible to review the entire SiPixelRawToDigi package now.

@perrotta
Copy link
Contributor

perrotta commented May 6, 2019

I am not sure how to undo the changes by code check. If you want, I can try to run
git push origin +HEAD
after I removed the commits from my local repo. Would that help? Or I can submit another PR. You are commenting on code that has nothing to do with this PR. Also, I do not think it is feasible to review the entire SiPixelRawToDigi package now.

Please don't mind if I don't like the clang prescriptions of the code checks: you can just concentrate on my comments for now.

Otherwise, you could submit another PR which only contains your original commits, profiting of the fact that code checks have been now momentarily disabled in order to speed up integrations for pre5.

@veszpv
Copy link
Contributor Author

veszpv commented May 7, 2019

Resubmitted this PR as PR26679 without the format checks for easier review.

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

5 participants