Closed tomeichlersmith closed 1 year ago
On Thu, Oct 8, 2020 at 1:46 PM Tom Eichlersmith notifications@github.com wrote:
EcalHexReadout is a class that we are now using for almost all translation between EcalID and real-space position, not just cutting up the module hexagons into cellular hexagons. With this in mind, it makes a lot more sense to call it something more general than EcalHexReadout, probably EcalGeometry would work best, and then it would line up with the provider that provides it EcalGeometryProvider.
I'm also going to take this opportunity to clean-up the Ecal precision digis and the HgcrocEmulator.
@omar-moreno https://github.com/omar-moreno I would love to put all of this Ecal-related stuff in the Ecal module. After the cmake changes you are working on, how difficult would it be to make a "Geometry" sub-module of Ecal (similar to how we are making "Event" submodules)? This way, SimCore and Ecal::Ecal could link to Ecal::Geometry and the source for Ecal::Geometry would be in the Ecal module.
This sounds like a good idea. I have already started doing something similar in SimCore (added SimCore/Geo) and plan to do the same in the Tracking module.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LDMX-Software/ldmx-sw/issues/923, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4JMXDZHJIMHAWUWYMYVL3SJYQL7ANCNFSM4SJHW6GQ .
Moving future updates from #873 here.
EcalHexReadout is a class that we are now using for almost all translation between EcalID and real-space position, not just cutting up the module hexagons into cellular hexagons. With this in mind, it makes a lot more sense to call it something more general than
EcalHexReadout
, probablyEcalGeometry
would work best, and then it would line up with the provider that provides itEcalGeometryProvider
.I'm also going to take this opportunity to clean-up the Ecal precision digis and the HgcrocEmulator. I need to make the collection name and pass name for the inputs configurable.
@omar-moreno I would love to put all of this Ecal-related stuff in the Ecal module. After the cmake changes you are working on, how difficult would it be to make a "Geometry" sub-module of Ecal (similar to how we are making "Event" submodules)? This way,
SimCore
andEcal::Ecal
could link toEcal::Geometry
and the source forEcal::Geometry
would be in theEcal
module.