Reopening CaloSurfaceStep extraction with material effects (draft)#1828
Reopening CaloSurfaceStep extraction with material effects (draft)#1828sophiemiddleton wants to merge 35 commits into
Conversation
|
Hi @sophiemiddleton,
which require these tests: build. @Mu2e/fnalbuild-users, @Mu2e/write have access to CI actions on main. ⌛ The following tests have been triggered for cfb40c2: build (Build queue - API unavailable) |
|
☀️ The build tests passed at cfb40c2.
N.B. These results were obtained from a build of this Pull Request at cfb40c2 after being merged into the base branch at 95f0a83. For more information, please check the job page here. |
brownd1978
left a comment
brownd1978
left a comment
There was a problem hiding this comment.
Overall this looks very complete. There may be merge conflicts with PR 1842, which I expect to get merged today or tomorrow. After that you can pull in the head and resolve them. Let me know if you need help with those.
I believe you need to test inner (and maybe outer) boundng cylinders. Isn't there material there too?
You may need multiple shellXing objects, depending on how big the step is, see how that's handled for the CRV.
The materials could be more accurate/detailed.
Eventually the CsI should be modeled, perhaps as a segmented (thick) Xing. A base class for that is planned, so not for this PR.
Eventually support materials should be added, mostly to reject tracks that hit them.
Is the source material (pipes) included, at least in aggregate?
| double z1_back_global = z1_global + diskHalfLen_1; | ||
|
|
||
| // Convert from global to local coordinates (relative to tracker center) | ||
| double tracker_z0 = tracker.g4Tracker()->z0(); |
There was a problem hiding this comment.
Please use GeomHandle det; det->toDetector() instead of doing this manually.
| straw-gas 0.0016980 0. 0. +2 0.78304 Argon 0 0.21696 CO2 1 -10 -20 -30 20.0 1.0 gas 0.01 | ||
| # Calorimeter materials | ||
| AluminumHoneycomb 0.03 0. 0. +1 100.0e-2 Aluminum 0 -10 -20 -30 20.0 1.0 solid | ||
| CarbonFiber 1.60 0. 0. +1 100.0e-2 Carbon 0 -10 -20 -30 20.0 1.0 solid |
There was a problem hiding this comment.
CF has other components (epoxy), but this is good enough to start.
There was a problem hiding this comment.
yes, I can definitely make these materials more complete, I just didnt want to add in too much in one go
| }; | ||
|
|
||
| template <class KTRAJ> bool ExtrapolateCaloMaterial::needsExtrapolation(KinKal::ParticleTrajectory<KTRAJ> const& fittraj, TimeDir tdir) const { | ||
| // Calorimeter has only ONE surface (unlike multi-foil predicates like ST). |
There was a problem hiding this comment.
As written, this won't catch intersections from tracks coming in through the inner edge. You could either add a cylinder on that, or convert the annulus to a disk. The cylinder will be more accurate, as it will correct for magnetic field effects up to the calorimeter material.
There was a problem hiding this comment.
yes, I was thinking abouit this a little but not gotten around to it yet
| // Fill validation plots | ||
| double momentum = fittraj.momentum(newinter.time_); | ||
| auto pos = newinter.pos_; | ||
| fillValidationPlots(momentum, disk_, pos.X(), pos.Y()); |
There was a problem hiding this comment.
This call should be behind a debug_ flag.
There was a problem hiding this comment.
yes, I have a debug setting, I guess this one was missed. I may remove these plots eventually though as per the below comment
| TH2F* h_intersection_efficiency_ = nullptr; | ||
| TH2F* h_frontpanel_hits_ = nullptr; | ||
| TH1F* h_momentum_degradation_ = nullptr; | ||
| TH1F* h_scatter_100mev_ = nullptr; |
There was a problem hiding this comment.
What's the intent behind these particular momenta?
There was a problem hiding this comment.
debugging plots, to help me understand if it was doing what I wanted
| std::unique_ptr<KKExtrap> extrap_; // extrapolations | ||
| bool makeValidationPlots_ = false; | ||
| // validation histograms for calorimeter material intersection | ||
| TH2F* h_intersection_efficiency_ = nullptr; |
There was a problem hiding this comment.
Is there a reason these plots can't be made downstream in an analysis module?
There was a problem hiding this comment.
I'm not sure, they need to talk with the internals of the extrapolation, so I'm not sure if the information would be availble in other places. I can also remove them once I'm happy its all good
| mutable ExtrapolateToZ TSDA_, trackerFront_, trackerBack_; // extrapolation predicate based on Z values | ||
| mutable ExtrapolateIPA extrapIPA_; // extrapolation to intersections with the IPA | ||
| mutable ExtrapolateST extrapST_; // extrapolation to intersections with the ST | ||
| mutable ExtrapolateCaloMaterial extrapCaloMat_; // extrapolation through passive calo materials (disk 0) |
There was a problem hiding this comment.
Can you make an array? Or name these D0 and D1?
|
thanks, I'll wait for your PR to merge and hope to finalize these comments then |
|
📝 The HEAD of |
4 participants
This pull request introduces calorimeter (Calo) geometry and surfaces into the KinKal geometry framework, enabling extrapolation and material modeling for the calorimeter disks. It adds the necessary data structures, construction logic, and configuration options to integrate the calorimeter with existing geometry and extrapolation tools. The most important changes are grouped below.
Calorimeter geometry integration
Caloclass inKinKalGeomto represent the calorimeter disks' geometry and surfaces, including construction from Calorimeter service parameters and accessors for all relevant surfaces (EMC_Disk_0/1_Inner/Outer/Front/Back) (KinKalGeom/inc/Calo.hh,KinKalGeom/src/Calo.cc) [1] [2].Caloobject into the main geometry (KinKalGeom) as a member, with accessor methods and construction inKinKalGeomMaker(KinKalGeom/inc/KinKalGeom.hh,GeometryService/inc/KinKalGeomMaker.hh,GeometryService/src/KinKalGeomMaker.cc) [1] [2] [3] [4] [5].Surface enumeration and mapping
SurfaceIdEnumand the associated name mapping to include calorimeter disk surfaces and the EMC front panel, ensuring unique identification and lookup for all new surfaces (DataProducts/inc/SurfaceId.hh,DataProducts/src/SurfaceId.cc) [1] [2].MakeSurfaceSteps_module.ccto handle calorimeter disk surface virtual detectors (CommonMC/src/MakeSurfaceSteps_module.cc) [1] [2].Configuration and extrapolation support
Mu2eKinKal/fcl/prolog.fcl) [1] [2] [3] [4] [5].KinKalGeom/CMakeLists.txt,Mu2eKinKal/CMakeLists.txt) [1] [2].Other improvements
KinKal::Diskto avoid ambiguity with other disk definitions (GeometryService/src/KinKalGeomMaker.cc) [1] [2] [3] [4].These changes collectively provide the infrastructure and configuration needed for calorimeter-aware tracking and extrapolation in the KinKal framework.