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

Hcal geometry condition updates + refactoring #1117

Closed
3 of 5 tasks
EinarElen opened this issue Nov 8, 2022 · 4 comments · Fixed by #1135
Closed
3 of 5 tasks

Hcal geometry condition updates + refactoring #1117

EinarElen opened this issue Nov 8, 2022 · 4 comments · Fixed by #1135
Milestone

Comments

@EinarElen
Copy link
Contributor

EinarElen commented Nov 8, 2022

Given the new and more complicated hcal geometry, there are more things we want to be able to ask the geometry condition. I want to take the opportunity when adding these to also try and clean things up in there a bit. @ehrlich-uva feel free to suggest other things you might need below

  • Scintillator bar length from HcalID
    • Added parameter for v14
    • Added parameter for prototype-geometries
    • Added parameter for v13
      Not done yet, not sure about what the correct lengths for the side hcal should be here. Took 3.1 m for back hcal, but that might be wrong? @cmantill do you have any input here?
  • Scintillator bar orientation from HcalID (no longer only relevant for the back hcal...) Not dealing with right now
  • Remove hacky code to handle v<14 geometries now that we have list[list]-parameters
@EinarElen
Copy link
Contributor Author

For the scintillator bar orientation, I'm thinking maybe we can get away with not handling that yet. Currently, only the v14 geometry has a side-hcal which is relevant for Ralf's scintillation simulation so... We can survive with handling it there

@ehrlich-uva
Copy link
Contributor

Is there a function that returns the version number of the geometry? If so, we can use some if/thens to use the older HcalDigitization methods for older geometry versions.

@EinarElen
Copy link
Contributor Author

There isn't currently, but i still think it would be valuable to have two distinct digiproducers and in that case we maybe wouldn't need it

@ehrlich-uva
Copy link
Contributor

Yes, we can keep both digiproducers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants