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

Run3-hcx373 Correct the HcalTopology class for 2 new geometry modes #46308

Merged
merged 10 commits into from
Oct 11, 2024

Conversation

bsunanda
Copy link
Contributor

@bsunanda bsunanda commented Oct 8, 2024

PR description:

Correct the HcalTopology class for 2 new geometry modes. Geometry mode is used to specify the detector scenario. LHC was the fixed version of the legacy detector. New modes are defined to specify the current situation with new ZDC assignment with the RPD detector (Run3) and the Phase2 setup (Run4) with no HE detector. It will be expanded in future to mark when HF DetIds were enlarged (2016), HE started expansion (2017) and HB had several depths (post LS2). Some of this is reflected in this version of HcalTopology. The usage of the modes was not correctly interpreted in the earlier version of the HcalTopology code.

PR validation:

Use the runTheMatrix test workflows

If this PR is a backport please specify the original PR and why you need to backport that PR. If this PR will be backported please specify to which release cycle the backport is meant for:

Backport to 14_1_X using #46309

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 8, 2024

cms-bot internal usage

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 8, 2024

-code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-46308/42132

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

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 8, 2024

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-46308/42133

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 8, 2024

A new Pull Request was created by @bsunanda for master.

It involves the following packages:

  • CondTools/Geometry (db)
  • Geometry/CaloTopology (geometry)

@Dr15Jones, @atpathak, @bsunanda, @civanch, @cmsbuild, @consuegs, @francescobrivio, @kpedro88, @makortel, @mdhildreth, @perrotta can you please review it and eventually sign? Thanks.
@JanChyczynski, @PonIlya, @ReyerBand, @fabiocos, @martinamalberti, @mmusich, @rsreds, @thomreis, @wang0jin, @yuanchao this is something you requested to watch as well.
@antoniovilela, @mandrenguyen, @rappoccio, @sextonkennedy you are the release manager for this.

cms-bot commands are listed here

@bsunanda
Copy link
Contributor Author

bsunanda commented Oct 8, 2024

@cmsbuild Please test

@Dr15Jones
Copy link
Contributor

It would seem to me that instead of having if ( mode_ == .... || mode_ ....) all over the code, to use a different new variable phase_ which is either Phase1 or Phase2 based on the value of mode_.

@bsunanda
Copy link
Contributor Author

+geometry

@bsunanda
Copy link
Contributor Author

@perrotta Please approve this

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.

This PR includes some updates/fixes with respect to the HcalTopology currently in CMSSW: please add the description of the rationale of those changes/fixes in the PR description, so that it can also remain as a future documentation (besides helping now the poor reviewer of the PR).

As far as I understand, the fixes are the following ones:

  • (1) Avoid undefined behaviour at L75 for modes different from LHC and SLHC
  • (2) Remove Run3 from the Phase2 modes, as it is erroneously now the case in the release

Then I remain with my doubt about L198 that I expect you can explain here (or fix, if needed)

((mode == HcalTopologyMode::SLHC) || (mode_ == HcalTopologyMode::Run3) || (mode_ == HcalTopologyMode::Run4))
? 500
: 87) {
numberOfShapes_((mode_ == HcalTopologyMode::LHC) ? 87 : 500) {
Copy link
Contributor

Choose a reason for hiding this comment

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

If I want to reproduce what in L82 I should write here:

Suggested change
numberOfShapes_((mode_ == HcalTopologyMode::LHC) ? 87 : 500) {
numberOfShapes_((mode_ == HcalTopologyMode::LHC) ? 87 : ((maxPhiHE_ > 72) ? 1200 : 500)) {

Could you please explain why they are different, if they need to be so? Or fix the wrong one, if they have to be the same?

@@ -571,8 +567,7 @@ bool HcalTopology::validRaw(const HcalDetId& id) const {

if (ok) {
if (subdet == HcalBarrel) {
if ((mode_ == HcalTopologyMode::SLHC) || (mode_ == HcalTopologyMode::H2HE) || (mode_ == HcalTopologyMode::Run3) ||
(mode_ == HcalTopologyMode::Run4)) {
if (phase2() || (mode_ == HcalTopologyMode::H2HE)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, I understand now that this is the fix: previously Run3 was erroneously counted together with the Phase2 modes.
Please, write it in the PR description, so that one can understand from there what you are fixing.

@Dr15Jones
Copy link
Contributor

Dr15Jones commented Oct 10, 2024

So I removed the constructor

HcalTopology(HcalTopologyMode::Mode mode,
int maxDepthHB,
int maxDepthHE,
HcalTopologyMode::TriggerMode tmode = HcalTopologyMode::TriggerMode_2009);

from the class, did git cms-checkdeps -a and rebuilt all the relevant parts of CMSSW and everything compiled just fine. That means we should remove that constructor for the class to help with maintenance.

The other reason to remove that constructor is it can lead to an instance of HcalTopology which will crash on certain calls because large number of member data expect the member data hcons_ to be set, which does not happen with that constructor.

@perrotta
Copy link
Contributor

So I removed the constructor

HcalTopology(HcalTopologyMode::Mode mode,
int maxDepthHB,
int maxDepthHE,
HcalTopologyMode::TriggerMode tmode = HcalTopologyMode::TriggerMode_2009);

from the class, did git cms-checkdeps -a and rebuilt all the relevant parts of CMSSW and everything compiled just fine. That means we should remove that constructor for the class to help with maintenance.

The other reason to remove that constructor is it can lead to an instance of HcalTopology which will crash on certain calls because large number of member data expect the member data hcons_ to be set, which does not happen with that constructor.

Thank you @Dr15Jones , I second your proposal.
It would also remove the ambiguity I pointed out in #46308 (comment) : still I would like to hear from @bsunanda which is the correct formulation for numberOfShapes_

@bsunanda
Copy link
Contributor Author

@perrotta Please sign this. I am preparing the correct implementation of HcalTopology given what I wrote earlier for different eras of HCAL. This version is adequate for CMSSW_14_1_X.

@perrotta
Copy link
Contributor

@perrotta Please sign this. I am preparing the correct implementation of HcalTopology given what I wrote earlier for different eras of HCAL. This version is adequate for CMSSW_14_1_X.

@bsunanda could you please at least reply to my question in #46308 (comment) ? Since there are two different computations of the same quantity in the two different constructors I think it is mandatory to understand whether it is correct that they are such different, and if not the wrong one must be fixed (or even removed, as suggested by @Dr15Jones )

@bsunanda
Copy link
Contributor Author

@perrotta At the moment the second constructor is not used and it won't create a mess. I shall surely remove it in the next version. It was left there because when we were changing the HcalTopology (some 10-12 years ago), some of the codes were still using HcalTopology without accessing Hcal..Const from EventSetup. That practice has disappeared as seen by Chris's test. So it is safe to remove it. If I remove this in this PR, this will trigger the tests and the whole process of integration
will be delayed.

@perrotta
Copy link
Contributor

@perrotta At the moment the second constructor is not used and it won't create a mess. I shall surely remove it in the next version. It was left there because when we were changing the HcalTopology (some 10-12 years ago), some of the codes were still using HcalTopology without accessing Hcal..Const from EventSetup. That practice has disappeared as seen by Chris's test. So it is safe to remove it. If I remove this in this PR, this will trigger the tests and the whole process of integration will be delayed.

Fine.
But which is the correct definition of numberOfShapes_ (fourth time I ask here....)? The one in the constructor that is used, or the one in the unused constructor?
Only if the correct definition is the one in the used constructor I can accept:

@bsunanda
Copy link
Contributor Author

@perrotta The first constructor is the right one. I shall remove the second constructor in my next PR

@perrotta
Copy link
Contributor

+db

  • This PR implements some necessary fix to the HcalTopology class:
    • Avoid undefined behaviour at L75 for modes different from LHC and SLHC
    • Remove Run3 from the Phase2 modes, as it is erroneously now the case in the release
  • It is understood that another (minor) fix is needed to remove a bugged constructor: a fix will be also provided and combined in the backport PR

@cmsbuild
Copy link
Contributor

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

@perrotta
Copy link
Contributor

urgent
(@cms-sw/orp-l2 could you please merge in time for the 1100 IB, so that the necessary actions can be taken at once to implement further fixes and prepare a backport?)

@mandrenguyen
Copy link
Contributor

+1

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.

6 participants