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

Extract SNR of tracks #126

Open
guiguem opened this issue May 21, 2018 · 4 comments
Open

Extract SNR of tracks #126

guiguem opened this issue May 21, 2018 · 4 comments
Assignees
Labels

Comments

@guiguem
Copy link
Member

guiguem commented May 21, 2018

It would be useful to extract the SNR of tracks as the bins average intensity of the track relative to the background shape.
We could then save it next to the TrackTotalPower as they carry a different information.
We could then do cuts on the snr of the tracks/events.

@cclaessens
Copy link
Contributor

The max SNR of a track would also be interesting.

@nsoblath
Copy link
Member

This sounds like a good idea. A few thoughts on the implementation:

  • The information probably needs to be extracted pretty early, when the spectrum discriminator is used.
  • KTDiscriminatedPoints1D and KTDiscriminatedPoints2D will need to be updated to include one more number: SNR
  • The two spectrum discriminators, KTSpectrumDiscriminator and KTVariableSpectrumDiscriminator will need to be updated to extract the SNR
  • Be sure to check where the two data classes are used, even other than in the STF, so that you know if anything else is impacted by this change. The HDF5 and ROOT Tree writers will definitely need minor changes, for instance.

@cclaessens
Copy link
Contributor

suggested_katydid_changes.pdf

After discussing with Mathieu we came up with this list of changes. I hope I summarized them correctly.
The processed tracks would get 7 new properties (3 SNR, 3 NUPs and number of identified track bins).
In addition we want to move some tasks from the STF (summing of power and producing procTracks) to other processors (discriminator and track processing).

I am not happy with the naming of the new track properties yet. For now, I used "Bin" and "Track" in the names to distinguish between properties that use power solely from the track bins and properties that use the combined power of adjacent bins.

@cclaessens
Copy link
Contributor

I forgot the changes to the sparse waterfall candidates. They need to include the new information too, so the track processing can access it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants