search

LDMX-Software / ldmx-sw

The Light Dark Matter eXperiment simulation and reconstruction framework.
https://ldmx-software.github.io
GNU General Public License v3.0
22 stars 20 forks source link

Detector Geometry Isolation #584

Closed tomeichlersmith closed 4 years ago

tomeichlersmith commented 5 years ago

Currently, a lot of different parts of the geometry description are hard-coded in various producers/analyzers/classes. Isolating the geometry description to one class in the DetDescr module would allow for all modules to access the same geometry details, making it standard across the framework. Additionally, keeping the geometry in one place will make it easier to update (and maybe automatically load from a gdml description) in the future.

I started the class on this branch to help with the event display development, but I think it deserves to be separate because it could be helpful for everyone.

Right now, it has the HCAL and ECAL geometries with some accessor functions that are specialized for the event display. At the end of the implementation file, a namespace wide instance is created called DETECTOR_GEOMETRY which can be used any where the header file is included.

bechenard commented 5 years ago

Hi Tom,

Great, that is going to be useful.

Bertrand

On 7/31/2019 8:37 AM, Tom Eichlersmith wrote:

Currently, a lot of different parts of the geometry description are hard-coded in various producers/analyzers/classes. Isolating the geometry description to one class in the DetDescr module would allow for all modules to access the same geometry details, making it standard across the framework. Additionally, keeping the geometry in one place will make it easier to update (and maybe automatically load from a gdml description) in the future.

I started the class on this branch to help with the event display development, but I think it deserves to be separate because it could be helpful for everyone.

Right now, it has the HCAL and ECAL geometries with some accessor functions that are specialized for the event display. At the end of the implementation file, a namespace wide instance is created called |DETECTOR_GEOMETRY| which can be used any where the header file is included.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LDMX-Software/ldmx-sw/issues/584?email_source=notifications&email_token=ABJ27JDEZU2RRZL52MUGYCDQCGWUNA5CNFSM4IIIAHT2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HCTHZ7A, or mute the thread https://github.com/notifications/unsubscribe-auth/ABJ27JEXSUIC3I7446UD65DQCGWUNANCNFSM4IIIAHTQ.

omar-moreno commented 5 years ago

Before doing anything here, I would like to see a presentation with an outline on approach and the class hierarchy you are envisioning. A lot of work has already been done on this and I want to make sure that whatever classes you are going to push wont clash with what has already been done.

Also, using a singleton is something I want to avoid for now.

tomeichlersmith commented 4 years ago

This would be a very large project, probably using an outside framework for working with detectors. My opinion is to use dd4hep (Detector Description 4 HEP), which is used for several other major experiments in HEP. It also has interfaces for event displays, ROOT, Geant4, and reconstruction pipelines.

Because this is such a large project, I think it would be best to delay this until a later release (like 2.1 or 2.2) so that the other major changes we have made can be gotten used to.

omar-moreno commented 4 years ago

Closing at this will be addressed by #592