A sim-level filter that selects and keeps only simhits in a collection that are directly associated with incoming beam electrons

[bryngemark]

Is your feature request related to a problem? Please describe. Need a way to benchmark beam electron counting against the actual number of beam electrons a system has seen.

Describe the solution you'd like A pure beam electron hit collection provides a clean sample of hits against which to benchmark algorithm performance. It automatically accounts for cases such as completely overlapping trajectories or electrons scattering out of acceptance.

Describe alternatives you've considered I have also thought of adding some more labelling to (non-)beam electron hits, but this is not the most pressing need. It would be straightforward to single out other types of hits to other collections. Having a separate collection makes it easy to compare individual events.

[jmmans]

This seems like a rather artificial distinction, doesn't it? A delta ray produced by a beam electron wouldn't be counted, but ionization caused by the beam electron would? What about soft brehms and Compton scatters? This seems terribly cutoff-dependent in a way which is hard to understand.

If the issue is to ignore effects of other detector elements (like backscatter off the calorimeter), why not just simulate with these turned off?

Is the necessary information already in the hit collections, or not? If it is, it seems you are mostly looking for a post-processing step that would select a subset of hits for your usage later in the simulation.

Jeremy

On 10/12/20 11:36 AM, bryngemark wrote:

Is your feature request related to a problem? Please describe. Need a way to benchmark beam electron counting against the actual number of beam electrons a system has seen.

Describe the solution you'd like A pure beam electron hit collection provides a clean sample of hits against which to benchmark algorithm performance. It automatically accounts for cases such as completely overlapping trajectories or electrons scattering out of acceptance.

Describe alternatives you've considered I have also thought of adding some more labelling to (non-)beam electron hits, but this is not the most pressing need. It would be straightforward to single out other types of hits to other collections. Having a separate collection makes it easy to compare individual events.

— 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/926, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFUPYH2GZIS7QQU3OINI5DSKMV7BANCNFSM4SNAQ2MA.

[bryngemark]

Indeed this is what I have, a postprocessing filter, and it is indeed not an infrared safe object definition :)

It is not intended for identifying everything that happens to an electron. It's intended for being able to see, for instance, if the electron counts based on clusters is heavily affected by backscattered secondaries, while tracking finds the right ones. And I agree that we can generate separate samples to understand the rate of them, but for benchmarking algorithm performance, being able to do this in the actual event, is very useful.

How I use this so far, to clarify, is to run hit reco+clustering+tracking on both the standard and the pure beam electron collection, for each event. It simplifies the identification of the number of findable tracks, if you will. Making the association of the truth info from the hit collections is possible, but not straightforward. (Imagine for instance a track made up of two hits from beam electrons and a delta ray, making a classification here becomes a choice too, but what I really want to know is, would I even have found this track?)

[tomeichlersmith]

To my knowledge, this is on trunk in the TrigScint module and was patched to be functionional with #1000 . Feel free to re-open if I am mistaken.