Enable reco of coldbox CRP4 data

[dladams]

Bottom coldbox data was taken this year with CRP4 and CRP5 and we would like to enable reconstruction (dataprep and downstream) of this data.

[dladams]

Wenqiang provided crpcb_bottom_process.fcl and top-level crp4_data_reco.fcl and I put these at dunesw/fcl/vdcolbox/reco and then modified them to use his intended config of the decoder tool. Here are the relevant snippets from a fcl dump:

...
tools:
...
crp4_decoder: {
DebugLevel: 0
DefaultCrate: 1
FileInfoLabel: "daq"
MaxChan: 10000000
SubDetectorString: "VD_Bottom_TPC"
tool_type: "PDHDDataInterfaceWIB3"
}
...
physics:
...
producers: {
caldata: {
BeamEventLabel: ""
ChannelGroups: ["cru"]
ChannelRanges: []
DecoderTool: "crp4_decoder"
DigitLabel: "tpcrawdecoder:daq"
DoAssns: "true"
DoGroups: "true"
IntermediateStates: []
LogLevel: 3
OnlineChannelMapTool: ""
OutputDigitName: ""
StatusLabel: "daq"
TimeStampName: ""
WireName: "dataprep"
module_type: "DataPrepModule"
}
...

With this config, we are able to open the file and get what looks like the correct timestamp but the ADC data is not found. Here a run log snippet:

...
DataPrepModule::produce: Run 20616-1, event 1, nproc=0
DataPrepModule::produce: Reading raw digits and status with decoder tool crp4_decoder.
DataPrepModule::produce: Real data event time: 1678813728 (2023-03-14 17:08:48 UTC)
DataPrepModule::produce: Event time high, low: 1678813728, 864227072
DataPrepModule::produce: WARNING: Event timing clocks product not found.
DataPrepModule::produce: Fetching digits and clocks with decoder tool.
DataPrepModule::produce: WARNING: Decoder tool returned 0
DataPrepModule::produce:   Digit count from tool: 0
DataPrepModule::produce:   Stats count from tool: 1
DataPrepModule::produce:   Clock count from tool: 0
...

@tomjunk do we have the right config for the decoder and should we expect the dataprep module written for the protoDUNE-SP I to work here? The module uses the interface from the decoder tool base class.

I will figure out where the data is being lost.

[wenqiang-gu]

@dladams We are now using apa={-1} to retrieve the data: here. But it turns out "-1" does not guarantee a readout of all APAs. Here is the implementation in the decoder.

In my tests, I have used apa={6} by following Tom's configuration for decoder.

[wenqiang-gu]

@dladams @tomjunk I made a PR to duneprototypes so that we can use a value apa={-1} to retrieve any APA. As indicated by Barnali at last week's meeting, this is also assumed in the development of other decoders.

[dladams]

I merged Wenqiang's PR and now get this log snippet:

...
Plugin version SecClnt v5.1.0 is incompatible with secztn v5.5.3 (must be <= 5.1.x) in sec.protocol libXrdSecztn-5.so
DuneEventFilter::filter: Selecting run 20616-1 event 1
DataPrepModule::produce: Run 20616-1, event 1, nproc=0
DataPrepModule::produce: Reading raw digits and status with decoder tool crp4_decoder.
DataPrepModule::produce: Real data event time: 1678813728 (2023-03-14 17:08:48 UTC)
DataPrepModule::produce: Event time high, low: 1678813728, 864227072
DataPrepModule::produce: WARNING: Event timing clocks product not found.
DataPrepModule::produce: Fetching digits and clocks with decoder tool.
DataPrepModule::produce: WARNING: Decoder tool returned 0
DataPrepModule::produce:   Digit count from tool: 3072
DataPrepModule::produce:   Stats count from tool: 1
DataPrepModule::produce:   Clock count from tool: 3072
DataPrepModule::produce: WARNING: Channel timing difference: 104925858054014187 (4.19703e+15 ticks).
DataPrepModule::produce: WARNING: Channel timing difference: 104925858054014187 (4.19703e+15 ticks).
DataPrepModule::produce: WARNING: Channel timing difference: 104925858054014187 (4.19703e+15 ticks).
DataPrepModule::produce: WARNING: Channel timing difference: 104925858054014187 (4.19703e+15 ticks).
...

The event timing warning (and presumably the long string of timing difference warnings) come from this code:

...
    art::InputTag itag1("timingrawdecoder", "daq");
    auto htims = evt.getHandle(itag1);
    if ( htims ) {
...
    } else {
      if ( logInfo ) {
        cout << myname << "WARNING: Event timing clocks product not found." << endl;
      }
    }
...

I.e. the trigger/timing event data is missing. @tomjunk Should we expect to find that event data here? If so, with what label?

[dladams]

In the vertical-drift analysis meeting today, Tom indicated the timing/trigger data is not being decoded for CRP4,5. So we presumably add the option to skip the timing checks leading to to the rrors above.

[dladams]

The decoder tool warning above appears because LogLevel is set to 3 and so is not a concern.

The warning "Event timing clocks product not found." comes about because the reading of the trigger/timing (RDTimeStamp) data product is hardwired with tag tag1("timingrawdecoder", "daq"). We can fix this by providing a fcl param for the trigger/timing label with a special value (e.g. "none") that skips the read of this container. The status (RDStatus) container is already handled in this way.

[dladams]

With the changes in DUNE/dunedataprep#27, I can now read the digits for CRP4 data:

I used the tools for CRP2 (top). We should add calibration, noise removal, metric plotters and event displays for CRP4,5.

Should I work on those?

[dladams]

For the above, I also updated crpcb_bottom_process.fcl to set all the container labels to "none". This is what we want because we are reading the data using the decoder tool.