search

SBNSoftware / sbncode

SBN Analysis Software
9 stars 27 forks source link

BNBRetriever module needs to be decoupled from ICARUS trigger fragment #302

Open PetrilloAtWork opened 2 years ago

PetrilloAtWork commented 2 years ago

The BNBRetriever module is currently using an ICARUS data fragment to extract the necessary beam gate information. The object sbn::ExtraTriggerInfo has recently be transferred to SBN (sbnobj), and this module should now rely on that data product.

jzettle commented 2 years ago

This is doable but it would be a philosophy change which means the POT accounting has to be run during stage0 after the decoding happens as opposed to before it when we have the raw data present which at least in my understanding is what is happening now.

PetrilloAtWork commented 2 years ago

My own understanding is that the PoT accounting was never required to be doable without decoding. Given that decoding is the first step in ICARUS data processing, I don't see the need for that feature to be supported in the production context. At most, one can argue that this module might be ran in the online monitoring (I don't discuss the merits of such option here). I don't know if the trigger decoding tool works in the online context (who can test that, BTW?). If it does not, I would rather pursue a solution for the decoder in the online monitoring than duplicating a sizable part of the trigger decoding in two modules.

jzettle commented 2 years ago

Sure, I understand I just wanted to lay that out. I have never tried running any part of that in the online monitor. What does the online monitor run as a fcl. Assuming the OM processing is just a subset of stage0 we can add this in there and try it it is presumably not prohibitive in terms of data size to run that as is