-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Account for layer offset when using waferZ in new geometry #27503
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-27503/10846
|
A new Pull Request was created by @clelange (Clemens Lange) for master. It involves the following packages: RecoLocalCalo/HGCalRecAlgos @perrotta, @cmsbuild, @kpedro88, @slava77 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready @slava77 comparisons for the following workflows were not done due to missing matrix map:
Comparison Summary:
|
+upgrade |
@@ -150,6 +150,10 @@ GlobalPoint RecHitTools::getPositionLayer(int layer, bool nose) const { | |||
} | |||
} else { | |||
const HGCalDDDConstants* ddd = get_ddd(geom_, geometryType_, fhOffset_, lay); | |||
if (geometryType_ == 1) { | |||
if (lay > fhOffset_) |
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.
Shouldn't this be ">="? (Just guessing...)
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.
No, the fhOffset_
is the last layer of EE (=28), and only for the first layer of the hadronic calorimeter (29) the offset correction (29-28=1) be used, since the layer numbering starts with 1.
Please test |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
@clelange , automatic tests show no difference in the D41 workflow 20434.0 |
@perrotta , I wouldn't expect any differences: there is only one method that's using this within CMSSW at the moment (see https://cmssdt.cern.ch/lxr/ident?_i=getPositionLayer) and that only uses the first layer of EE (https://github.com/cms-sw/cmssw/blob/master/RecoEgamma/EgammaTools/src/EgammaPCAHelper.cc#L330). However, for code that's developed outside the CMSSW repository, this shows (the expected) differences. |
+1
|
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. @davidlange6, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2) |
as far as I can see there should not be real conflict with #27485, so it looks ok to integrate |
+1 |
PR description:
There is a bug in
RecHitTools::getPositionLayer(int layer, bool nose)
: when getting the z position of the wafer, one needs to account for the FH (HGCalSi) offset, starting the layer number at 1 instead of continuing to count up beyond EE.PR validation:
Ran in D41 (
geometryType_ == 1
) and instead of getting z = 0 for layers > 28, I actually obtained increasing z values:FYI @bsunanda