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
Pandora is sometimes able to tag a particle with a time (cathode-crossing tracks are the case in ICARUS and presumably SBND).
The information of that time should be stored in CAF data.
In fact, it may be conceivable that several time estimations are available (from matching with light, with CRT, and from TPC reconstruction, for example) and one might even want to accommodate all of them and let the analyser choose which one they believe most.
Anyway, for this one, a default value of "non-assigned" is needed, and then I recommend the time to be stored in the standard CAF time unit and with the same time reference as the reconstructed optical flashes (beam gate time? this point is topic of a different discussion).
The text was updated successfully, but these errors were encountered:
I think PR #308 addressed it for the time being.
We'll want the time from PMT and CRT when they become available, but that's not for the current release.
Up to you if you prefer to close this one or move its target.
Pandora is sometimes able to tag a particle with a time (cathode-crossing tracks are the case in ICARUS and presumably SBND).
The information of that time should be stored in CAF data.
In fact, it may be conceivable that several time estimations are available (from matching with light, with CRT, and from TPC reconstruction, for example) and one might even want to accommodate all of them and let the analyser choose which one they believe most.
Anyway, for this one, a default value of "non-assigned" is needed, and then I recommend the time to be stored in the standard CAF time unit and with the same time reference as the reconstructed optical flashes (beam gate time? this point is topic of a different discussion).
The text was updated successfully, but these errors were encountered: