Trigger should not store events containing a veto

[coderdj]

Specifically a BUSY or HE veto. Since our veto logic operates on large S2s, even if the whole S2 is blocked the trigger will presumably still trigger on the large S1. These events are excluded from every analysis and I can't think of a reason to keep them.

Of course if someone thinks of a reason why we want to keep these events it could be discussed.

[sanderbreur]

Hi Dan, For the BUSY veto I completely agree, the only reason to keep these that I can think of is if there's some very high energy analysis being done and then need to calculate the efficiency. As I assume that the busy could be energy dependent for example for muons signals that could be a use case but I don't know anybody who did that. For the high-energy veto I do have a reason to keep these events. Because for the alpha events in 220 radon calibration data we can do a full analysis on the S1 signals and we don't need to use S2 signals. This has been shown by both Miguel and my own analyses, because we can use the S-1 area friction top to determine the depth. Use cases are: showing the S1 spectrum for the radon 220 chain, determining the light yields (especially importance for data Monte Carlo comparison) and determining the time evolution of the radon daughters. I am assuming the reason for bringing it up is data reduction? Because without the S2 information I expect these events do not contain much data, am I correct? If we would throw away these events then we would needs to start taking 220 radon calibration data without the high-energy veto on, which I think will take up much more data. s Op wo 30 aug. 2017 om 12:37 schreef Daniel Coderre <notifications@github.com

…

: Specifically a BUSY or HE veto. Since our veto logic operates on large S2s, even if the whole S2 is blocked the trigger will presumably still trigger on the large S1. These events are excluded from every analysis and I can't think of a reason to keep them. Of course if someone thinks of a reason why we want to keep these events it could be discussed. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#605>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGNstQBjLvnWge_wLwgg6QnUsioJFeBkks5sdTtWgaJpZM4PHMJG> .

[coderdj]

I don't really buy your physics case. We have other handles on the light yield and we've seen the Rn220 spectrum. Are there physics inputs derived from these numbers? If so I would be a little careful. I'm not sure how efficient the HE veto is at telling a large S1 from an S2* so your distributions could be biased in the case that certain S1s get vetoed and others don't. At least we'd have to check it.

But even if we decide to allow HE-vetoed events through in Rn220 we could still include the logic to drop them in neutron generator data, for example.

In both cases we have a configurable prescale that allows us to record a subset of full, unbiased events.

• Edit: it works on width but we're dealing with an analog sum waveform that gets saturated and distorted at various levels (lastly in the fans) so not clear that it's infallible

[JelleAalbers]

Besides S1-analyses these events are used by the S2/tdiff cut (assuming at least some of the S2 is saved some of the time). Are there any estimates on the amount of data reduction that removing them would achieve?