You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The software-technical aspect of this project (if the collaborator is interested) would be to resolve #976 (TLDR: there is a copy of the cluster-finding infrastructure code in both ECal and HCal and removing that copy is preferable to avoid duplicating bugs in the future.) and potentially refactor the current code set to be more flexible and/or easier to use.
The technically-complicated software is already present, we just need more detailed study on how to define the "metric" that should be used for determining when hits are "close enough" to be in the same cluster.
We could look into refactoring this algorithm, but since the clusters are entirely determined by the "metric" (via cluster weights), it is already general enough and ready to be tuned to our use case.
Known Issues
These are obvious issues that I can see when looking at the code without even running it.
The cluster producer attempts to work from ecal digis since it was written during a time when the separation between digis and rec hits was not made. This line needs to be updated to use the rec hits instead.
The current example cluster weighting strategy uses linear-energy-fraction, but we should probably use log-energy-fraction (lnE/lnE) since its more physically motivated.
The software-technical aspect of this project (if the collaborator is interested) would be to resolve #976 (TLDR: there is a copy of the cluster-finding infrastructure code in both ECal and HCal and removing that copy is preferable to avoid duplicating bugs in the future.) and potentially refactor the current code set to be more flexible and/or easier to use.
The technically-complicated software is already present, we just need more detailed study on how to define the "metric" that should be used for determining when hits are "close enough" to be in the same cluster.
This is a C++ project but would "light C++" in the sense that the software-complicated stuff is there, we just need input on the physics-complicated stuff. (Basically, defining different "weights" like https://github.com/LDMX-Software/ldmx-sw/blob/trunk/Ecal/include/Ecal/MyClusterWeight.h that allow comparison of different clustering "metrics").
Summary of Cluster Algorithm
EcalClusterProducer creates a Templated Cluster Finder which requires an input cluster weighting class (for example, MyClusterWeight). This cluster finder then iteratively merges WorkingClusters until no more can be merged. The final set of working clusters are the completed clusters.
We could look into refactoring this algorithm, but since the clusters are entirely determined by the "metric" (via cluster weights), it is already general enough and ready to be tuned to our use case.
Known Issues
These are obvious issues that I can see when looking at the code without even running it.
The cluster producer attempts to work from ecal digis since it was written during a time when the separation between digis and rec hits was not made. This line needs to be updated to use the rec hits instead.
ldmx-sw/Ecal/src/Ecal/EcalClusterProducer.cxx
Lines 33 to 34 in c25fab3
The current example cluster weighting strategy uses linear-energy-fraction, but we should probably use log-energy-fraction (lnE/lnE) since its more physically motivated.
ldmx-sw/Ecal/include/Ecal/MyClusterWeight.h
Line 35 in c25fab3
We probably want to include a requirement on the minimum number of hits to avoid clustering a few small noise hits that happen to be near each other.
The text was updated successfully, but these errors were encountered: