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

Detector Parameters Update: Hadron Endcap HCal #572

Closed
Chao1009 opened this issue Oct 12, 2023 · 4 comments
Closed

Detector Parameters Update: Hadron Endcap HCal #572

Chao1009 opened this issue Oct 12, 2023 · 4 comments
Assignees
Labels
topic: calorimetry topic: forward Positive-rapidity detectors (hadron-going side)

Comments

@Chao1009
Copy link
Contributor

A series of smaller issues from #552
det: new value from 2023/09/27 parameter table
sim: current simulation value as of 2023/10/11
template_var: from which we extract the sim value in compact files. Empty means we do not know.
stat: Correct, Missing, or Mismatched

Please implement the new detector parameters, and try to fill in the template_var for the Missing ones if you think it's important for future simulation/design comparison.

Here is the detailed report for this detector subsystem:

HADRON DIRECTION END CAP, Hadron Calorimeter, : 
                           det    sim       template_var        stat
Length (cm)              140.0  140.0  {{LFHCAL_length}}     Correct
Inner Radius (cm)         17.5    0.0                  0  Mismatched
Outer Radius (cm)        267.0  270.0    {{LFHCAL_rmax}}  Mismatched
Offset from Center (cm)  359.6    NaN              Empty     Missing
Physical Start (cm)      359.6  363.2    {{LFHCAL_zmin}}  Mismatched
Physical End (cm)        499.6  503.2    {{LFHCAL_zmax}}  Mismatched
@rymilton
Copy link
Contributor

Hi, the hadron endcap HCal is not my detector. I am the liaison for the insert (which is not in the detector parameters spreadsheet for some reason). The ORNL folks are leading the HCal/LFHCAL.

@Chao1009
Copy link
Contributor Author

Hi @FriederikeBock, would you plan to verify and update the related detector parameters in the simulation? Please let us know if you have any questions or need help.

@FriederikeBock
Copy link
Contributor

@Chao1009 I'm not so sure how to help here.


    <constant name="LFHCAL_zmin"          value="EcalEndcapP_zmin + EcalEndcapP_length"/>
    <comment> LFHCAL is 140 cm total, but current implementation leaves the final 10 cm empty </comment>
    <constant name="LFHCAL_length"        value="140.0*cm"/>
    <constant name="LFHCAL_zmax"          value="LFHCAL_zmin + LFHCAL_length"/>

z min and max are defined via other detector parameters. So it seems someone is going beyond their allotted volume ahead of the LFHCal.
A similar thing applies for the outer radius.

 <constant name="LFHCAL_rmax"          value="HcalBarrel_rmax"/>

Even if it should not affect us entirely, as our detector is not defined as a disc but rather as single placement of 8M modules. That's why I also didn't define an inner radius, as I can't.

Not sure whether this is really helpful.
Regards,
Fredi

@kkauder
Copy link
Contributor

kkauder commented Nov 22, 2023

@Chao1009 @FriederikeBock , I chased it down to ForwardServiceGap_length which is 13.6 cm in definitions.xml but 9.6 cm in the table. I'll make a PR, this should affect all forward detectors so maybe best to run the report again after merging.

github-merge-queue bot pushed a commit that referenced this issue Nov 22, 2023
…600)

### Briefly, what does this PR introduce?
The latest table
https://eic.jlab.org/Geometry/Detector/Detector-20231031150001.html has
a shorter service gap. This should have a knock-on effect on all forward
detectors that ultimately depend on `ForwardServiceGap_zmin`

### What kind of change does this PR introduce?
- [x] Bug fix (issue #572 , #571 , possibly more)
- [ ] New feature (issue #__)
- [ ] Documentation update
- [ ] Other: __

### Please check if this PR fulfills the following:
- [ ] Tests for the changes have been added
- [ ] Documentation has been added / updated
- [ ] Changes have been communicated to collaborators

### Does this PR introduce breaking changes? What changes might users
need to make to their code?
No

### Does this PR change default behavior?
Yes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: calorimetry topic: forward Positive-rapidity detectors (hadron-going side)
Projects
Development

No branches or pull requests

4 participants