NTB Decoder and data product

[tomjunk]

This PR adds a producer module that reads Nevis Trigger Board (NTB) fragments (or container fragments) and writes out a new data product called raw::ntb::sbndntb. These can be browsed in the Events TTree in a decoded artROOT file.

docDB 37987

This PR starts out as a draft because it depends on sbndaq-artdaq-core PR 108

SBNSoftware/sbndaq-artdaq-core#108

which needs to be merged and included in a release before this decoder will work. There are headers for the NTB fragment and the format of the contents of that fragment, as well as a bugfix to the offsets within the data structure in that PR.

This code has been tested with running on an already-decoded artROOT file, though a raw DAQ file will also work as the input NTB data fragments are the same:

lar -c runntbdecoder.fcl decode_data_evb02_EventBuilder2_art1_run15040_2_20240717T115613-84aff87b-0059-4c97-8de9-0dcbf47d2e51.root

and plots from browsing the sbndntb data product in the output rootfile follow.

[tomjunk]

Many thanks to Ibrahim for releasing sbndaq_artdaq_core v1_09_02of1 which has the necessary header files for the NTB fragment and data format, and also sbncode v09_91_02_02 which depends on sbndaq_artdaq_core v1_09_02of1. This PR can now be addressed. It has already been tested and put to use -- see Seokju Chung's impressive timing study in SBN-doc-37987-v1. I include here some plots from run 15040 that I redecoded today to test that the chain works with the released sbncode and sbndaq_artdaq_core.

This PR has the added benefit of including the fixed PTB_content.h that was also included in sbndaq_artdaq_core v1_09_02of1 and undoes an unintentional clobber made earlier this year (by ICARUS!) of SBND's PTB_content.h.

[bear-is-asleep]

trigger build LArSoft/lar*@LARSOFT_SUITE_v09_91_02 SBNSoftware/sbncode@56dc342f SBNSoftware/sbnobj@a4b93770 e303cbe2 SBNSoftware/sbnanaobj@bug/coackley_ciCafv09_91_02

[FNALbuild]

✔️ CI build for LArSoft Succeeded on slf7 for c14:prof -- details available through the CI dashboard

[FNALbuild]

✔️ CI build for LArSoft Succeeded on slf7 for e26:prof -- details available through the CI dashboard

[FNALbuild]

❌ CI build for SBND Failed at phase build SBND on slf7 for c14:prof -- details available through the CI dashboard

🚨 For more details about the failed phase, check the build SBND phase logs

parent CI build details are available through the CI dashboard

[FNALbuild]

❌ CI build for SBND Failed at phase build SBND on slf7 for e26:prof -- details available through the CI dashboard

🚨 For more details about the failed phase, check the build SBND phase logs

parent CI build details are available through the CI dashboard

[bear-is-asleep]

trigger build LArSoft/lar*@LARSOFT_SUITE_v09_91_02 SBNSoftware/sbncode@56dc342f SBNSoftware/sbnobj@a4b93770 e303cbe2 SBNSoftware/sbnanaobj@bug/coackley_ciCafv09_91_02

[FNALbuild]

✔️ CI build for LArSoft Succeeded on slf7 for c14:prof -- details available through the CI dashboard

[FNALbuild]

✔️ CI build for LArSoft Succeeded on slf7 for e26:prof -- details available through the CI dashboard

[FNALbuild]

❌ CI build for SBND Failed at phase ci_tests SBND on slf7 for c14:prof - ignored failure for unit_test - ignored warnings for build -- details available through the CI dashboard

🚨 For more details about the failed phase, check the ci_tests SBND phase logs

parent CI build details are available through the CI dashboard

[FNALbuild]

⚠️ CI build for SBND Warning at phase ci_tests SBND on slf7 for e26:prof - ignored warnings for build -- details available through the CI dashboard

🚨 For more details about the warning phase, check the ci_tests SBND phase logs

parent CI build details are available through the CI dashboard

[bear-is-asleep]

Hi @tomjunk the CI is working now. I did see that one of the reco1 products changed, which is a bit strange

1072: Check for differences in the size of data products
1073: difference(s)
1074: 
1075: 129c129
1076: < Reco1 | gaushit |  | art::Assns<recob::Wire,recob::Hit,void> | 12594
1077: ---
1078: > Reco1 | gaushit |  | art::Assns<recob::Wire,recob::Hit,void> | 12595
1079: 132c132
1080: < Reco1 | gaushit |  | std::vector<recob::Hit> | 12594
1081: ---
1082: > Reco1 | gaushit |  | std::vector<recob::Hit> | 12595

But I think we are safe to approve!

[bear-is-asleep]

Approved for merge

[tomjunk]

Very good @bear-is-asleep ! I cannot imagine how the NTB decoder would impact the gaushit finder. Maybe some random number or uninitialized variable somewhere in the TPC processing / hit finding chain? It's just one out of 1295 so possibly hard to track down.

[bear-is-asleep]

Very good @bear-is-asleep ! I cannot imagine how the NTB decoder would impact the gaushit finder. Maybe some random number or uninitialized variable somewhere in the TPC processing / hit finding chain? It's just one out of 1295 so possibly hard to track down.

May be some stochastic processing within the CI that caused this, it's not a big enough deal to hold off on merging, though.