-
Notifications
You must be signed in to change notification settings - Fork 61
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
Fix segmentation position calculation for Allegro ECal. #423
base: main
Are you sure you want to change the base?
Conversation
Depends on PR#1384 from DD4hep (AIDASoft/DD4hep#1384), and requires a corresponding change in k4RecCalorimeter. |
Thank you for your PR. I think your approach is correct. However, I was wondering if it makes more sense that this extra information is stored as a data extension of the detector element, to be later retrieved by the segmentation itself and copied internally. A data extension would be easier to retrieve later during the reconstruction steps. @BrieucF @giovannimarchiori do you have idea about some key information that you would like to attach to the ECAL? I am not sure it is the best reference, but for example this is the data extension for the drift chamber [link] Nevertheless, I remember what you noticed that the initialization of the internal cache of the segmentation can not happen within the constructor, so it has to be done later. I think that step is unavoidable. |
Hi, The detector geometry appears to be accessible through the handle [link]. If you could store the geometry details as a data extension of the detector element, it could provide a more elegant solution. Please let me know if you require further support. |
Hi @atolosadelgado, we have layer radial info stored as dd4hep::rec::LayeredCalorimeterData in the C++ builder of the detector k4geo/detector/calorimeter/ECalBarrel_NobleLiquid_InclinedTrapezoids_o1_v04_geo.cpp Line 769 in 915923d
Is this the "data extension" you are proposing, or is it something different? |
Yes, that is. This subdetector has a data extension of type My point is that the segmentation seems capable of retrieving the detector element and its data extension. Therefore, I’m wondering if the code in this PR, which creates an internal object of type |
Thanks for the comments and suggestion. I'll take a look and see if that approach is workable. |
Fix the calculation of cell position for FCCSWGridModuleThetaMerged_k4geo. Also add a layer() method to that class to extract the layer from a cell ID.
bd6c23a
to
9d2ee1e
Compare
hi - So here's a stab at storing the derived geometry information as DetElement The code is a bit nicer this way. The tradeoff is that it is very roughly As far as LayeredCalorimeterData, it doesn't have the information we want An alternative would be to have the extension filled in createECalBarrelInclined |
Hi, You are right that the data extension is expected to be initialized together with the geometry builder. If it can not be used as read-only information by the segmentation, then it is not a good solution, I am sorry I misunderstood what the code was doing. If you roll back to your original implementation, I can merge it. Thank you for your time. |
Fix the calculation of cell position for
FCCSWGridModuleThetaMerged_k4geo.
Also add a layer() method to that class to extract the layer from a cell ID.
BEGINRELEASENOTES
ENDRELEASENOTES