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

InitializeFromConfigFile - Added flag to remove one hit tracks #46

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

JPorron
Copy link

@JPorron JPorron commented Aug 30, 2024

JPorron Ok: 17 Powered by Pull Request Badge

@JPorron
Copy link
Author

JPorron commented Aug 30, 2024

It is quite common for events to show one hit tracks that are clearly not a product of a small ClusterDistance in the track creating process, but an independent (usually low energy) hit. This is no problem when we use MaxTrack observables, as they are not affected by the extra track, but if we want to limit ourselves to 1 track event (the ones we are interested in) these extra tracks will screw the number of tracks cut, as limiting ourselves to 1 track events will exclude many interesting events due to them having more than one track because of these 1 hit tracks.

The creation of these one hit tracks does NOT seem to be due to a bad selection in the goodSignal parameters (that might make noise signals be considered as good signals) as the hits are produced by good shaped signals, but in a strip far from the others:

image
Fig 1: Example of a event where an extra one low energy hit track is created.

image
Fig 2: The raw signal of the event. 11 hits are found in the Fig. 1, corresponding to the 11 signals over the red line.

image
Fig 3: The good signals that lead to the hits. These signals seem to be okay so the extra signal far from the rest will always produce a hit, as it is a good signal.

I don´t know if these signals make physical sense, as the appear to be quite coincident to the event (happening a little later than the event). The X position also seems correct - The delay in the signal might just be a product of the algorithm that finds the maximum of the signal or the shape of the signal. In any case, we have 2 options:

  • Assume that the hit is part of the event and correct the hit position, by improving the algorithm, for example, so that it is contained in the track.
  • Whatever the nature of the hit, if it is not in the track and produces a new one hit track it must be removed, as it contributes nothing to the MaxTrack, but messes with the track number observable.

When the "ignoreOneHitTracks" flag is TRUE the same hits are found, but the one hit track is not created (effectively ignoring these outsider hits). We can see that the energy of the tracks is the same energy as the hits energy minus the energy of the hit that now does not lead to a one hit track, but the MaxTrack observables have not changed (as the hit was never a part of the MaxTrack).

image
Fig 4: Same event without the one hit tracks. The MaxTrack is not affected but the energy of the tracks is now not the same as the energy of the hits.

We go from:

image
image
Fig 5: Percentage of 1 track events in a certain run before (up) and after (down) removing the one hit tracks. Cases where we gor from Figure 1 to Figure 4.

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.

1 participant