Skip to content
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

Tune clustering within the ECal #1394

Open
tomeichlersmith opened this issue Aug 19, 2024 · 0 comments · May be fixed by #1416
Open

Tune clustering within the ECal #1394

tomeichlersmith opened this issue Aug 19, 2024 · 0 comments · May be fixed by #1416
Labels

Comments

@tomeichlersmith
Copy link
Member

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.

std::vector<ldmx::EcalHit> ecalHits =
event.getCollection<ldmx::EcalHit>("ecalDigis", digisPassName_);

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.

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.

@Lysarina Lysarina linked a pull request Aug 28, 2024 that will close this issue
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant