Skip to content

Conversation

@bryngemark
Copy link
Contributor

I am updating ldmx-sw, here are the details.

What are the issues that this addresses?

This allows association back to hits from clusters that were associated with PF tracks in the PFlow algorithm. It also includes a first go at a pileup electron identifier processor, that subtracts hits associated to high-momentum tracks from the ecal rechit collection (or rather, makes a new collection without those hits).

Check List

  • I successfully compiled ldmx-sw with my developments.
  • I read, understood and follow the coding rules.
  • I ran my developments and the following shows that they are successful.

Plot showing 10 2e inclusive events, ecal rec hits x: black is all hits, red is after pileup removal. This is not at all optimized yet (clustering needs improvements) but the principle works.

ecalRecHits_2e_allBlack_noPUred

Copy link
Member

@tomeichlersmith tomeichlersmith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking good, I have a few cleanup requests and one comment about sharing EcalGeo information with CLUE.

bryngemark and others added 2 commits October 2, 2025 16:32
Remove remnant of attempt to set hits directly

Co-authored-by: Tom Eichlersmith <31970302+tomeichlersmith@users.noreply.github.com>
Co-authored-by: Tom Eichlersmith <31970302+tomeichlersmith@users.noreply.github.com>
@bryngemark
Copy link
Contributor Author

The failing histogram tests are caused by a name change clusterless --> unclustered (which in turn is no biggie, just reflects the difference in perspective between a more seasoned particle physicist and a happy algorithm developer)

Comment on lines +38 to +40
std::vector<double> layer_thickness = {2., 3.5, 5.3, 5.3, 5.3, 5.3,
5.3, 5.3, 5.3, 5.3, 5.3, 10.5,
10.5, 10.5, 10.5, 10.5};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not true for v15 anymore

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's right, and tom pointed out that we should look this up instead of hardwiring it. i agree, and, i didn't introduce this part myself and don't really have time to work on it in the near future. would you be ok with making a new issue for this instead?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, makes sense!

Examples
--------
from LDMX.Recon.pfReco import pileupFinder
p.sequence.append( pileupFinder )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest to add this to the 2e CI

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does it make sense to do this without also developing a corresponding DQM analyzer?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say it still makes a technical check on it, we can see how the timing changes, etc. The DQM should anyway be it's own processor that we can add whenever it's developed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants