search

SBNSoftware / sbnana

3 stars 14 forks source link

Add logic for FileReducer to still make sure it writes out rejected records if they contain POT information #55

Closed cjbacchus closed 2 years ago

cjbacchus commented 2 years ago

...tag them as "husks" and make CAFAna skip those records.

Depends on https://github.com/SBNSoftware/sbnanaobj/pull/40 which adds the flag in question

This still needs to be tested. I am struggling a little because of the tortured git history of the SRBNBInfo object. Easiest thing I think is to get that part merged back into main.

Observations

PetrilloAtWork commented 2 years ago

My opinionated self:

  • Are we counting number of spills properly in data, analogous to MC's nGenEvent? I think the BNB accounting gives us the mechanism to do that, but I don't think we actually propagate the info all the way through

I somehow doubt it. The information is expected to be in sbn::ExtraTriggerInfo (I think that is gateCountFromPreviousTrigger), and maybe @jzettle knows whether it is filled at all by ICARUS trigger decoder. Then whether it is propagated to CAF is yet another question.

  • We have first_in_file and first_in_subrun flags at the moment. I think they only support this use-case. Should we scrap them and just make the test be "pot field is non-empty"?

I would encourage to get rid of them. Their name is misleading, too, as they actually mark a art (sub)run transition that happens at any input and output file change (and, kindly, on (sub)run changes too).

  • If you apply a slice cut in FileReducer that removes all slices, the containing spills will still be kept, with the slice list emptied out. The only way to remove spills and get this husk state is with a spill cut. Should we add some kind of "drop zero-slice spills" option to FileReducer?

Too much of a user question for me to have a motivated opinion... ~An alternative that is not the same (but shares one relevant effect) is to allow skipping the preservation of POT information into the reduced files, and in that case the husk bit may be reset. Then slice lists with husk bits false can be unconditionally dropped. Not sure if this makes any sense...~ [edit: reading the code and re-reading the description I realize that the implementation is different from an earlier draft we talked about and which i was thinking of]