You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Similar to the high energy veto, we might also cut out a ROI where we have most PMTs firing at the edge of the TPC. These records are going to be fiducialized later anyway, we could save a lot of storage if we already cut at the low level.
The text was updated successfully, but these errors were encountered:
This is indeed a nice idea. Just for reference here is a similar concept that Lukas tried to implement for XENON1T in hardware, using the hardware HEV. The DAQ was never cabled for it, so we don't know if it ever worked.
They were afraid of multi-scatter events leaking into the NR band, so I guess in software we also need to be careful not to produce extra "backgrounds". Although, in software it also should be much easier to track the issued vetoes and to make a quality cut based on that.
I also like the idea. I think in software it is much easier to establish such a veto as we can first keep everything and build the veto based on events. (This only makes sense if you would like to just reduce the amount of data. Obviously it will not help with processing in that case.)
Similar to the high energy veto, we might also cut out a ROI where we have most PMTs firing at the edge of the TPC. These records are going to be fiducialized later anyway, we could save a lot of storage if we already cut at the low level.
The text was updated successfully, but these errors were encountered: