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.

[dladams]

I am also using my own dataprep tool name list. I should check and perhaps modify whatever @wenqiang-gu is using.

[wenqiang-gu]

Thank you, @dladams. My configuration is adapted from CRP2/3. Could you help check if they are consistent with yours?

[dladams]

I think the next step is to define channel ranges that match the FEMB views that we can use for CNR. I will begin working on this now.

[dladams]

Adding FEMB-view channel ranges is discussed in DUNE/dunedataprep/28.

[dladams]

The coldbox bottom fcl crpcb_bottom_process.fcl has these includes:

#include "services_vdcoldbox.fcl"
#include "workflow_reco_crpcb_top.fcl"
#include "vdct_decoder.fcl"
#include "protodune_tools_dune.fcl"
#include "vdcb2_tools.fcl"
#include "vdcb_dataprep_sequences.fcl"
#include "channelstatus_vdcrp2.fcl"
#include "channelstatus_vdcrp3.fcl"

It is disconcerting to see the references to top decoder and channel status here.

We presumably don't yet have any bad channels and so I created empty bad channel lists for crp4 and 5 and put them is similarly named file that included in place of the last two lines. And I dropped the vdct_decoder line.

But I can't test this due to unrelated error:

Failed to parse the configuration file 'run.fcl' with exception
---- Parse error BEGIN
  Local lookup error
  ---- Can't find key BEGIN
    dune_vd_crp2_sp (at part "dune_vd_crp2_sp")
  ---- Can't find key END
  at line 25, character 24, of file "/home/dladams/proc/build/dev01/workdir/localProducts_dunesw_v09_72_01d00_e20_prof/dunesw/v09_72_01d00/fcl/workflow_reco_crpcb_top.fcl"
  included from line 2 of file "/home/dladams/proc/build/dev01/workdir/localProducts_dunesw_v09_72_01d00_e20_prof/dunesw/v09_72_01d00/fcl/crpcb_bottom_process.fcl"
  included from line 1 of file "/home/dladams/proc/build/dev01/workdir/localProducts_dunesw_v09_72_01d00_e20_prof/dunesw/v09_72_01d00/fcl/crp4_data_reco.fcl"
  included from line 8 of file "./vdbcrp4proc.fcl"
  included from line 1 of file "./run.fcl"
  
     wclsdatanfsp:       @local::dune_vd_crp2_sp
                         ^
---- Parse error END

apparently due to recent dunesw commit from @wenqiang-gu . I sent mail to him about that.

[dladams]

We need new dunereco to fix preceding problem according to @wenqiang-gu.

[dladams]

With updated dunereco, I can now get a little further. I replace reference to @Local::data.ChannelStatusService_vdcrp2 with @Local::data.ChannelStatusService_vdcrp4 and now can run fine. Changes to duneprototypes and this package are pushed.

[dladams]

Tom reports that the trigger/timing data should now be available (update duneprototypes) for the vertical-drift, bottom-readout coldbox data:

Hi David, Wenqiang, Barnali,
 
  Sorry to be so slow on this -- I was away for a week after it was brought up in the VD analysis meeting.
It turns out Barnali already wrote a trigger data product reading module for ProtoDUNE-HD, and I tested
it out on a VD coldbox  data file.  She had added the necessary DAQ data products to the classes.h and
classes_def.xml files in dunecore/DuneObj, and a decoder module in duneprototypes/Protodune/hd
There's no need for a tool here as the trigger data are small and can just all be copied into the art event.
 
I updated the fcl file
 
runvdcoldboxdecodercrp45.fcl
 
in duneprototypes to call Baranli's module and tested it out.  It seems to work -- it makes maps between
sourceIDs and trigger candidate, trigger activity, and trigger primitive vectors.  The VD coldbox file I looked
at seems only to have trigger candidate info.    The output maps seem to be
a bit complicated for ROOT's TTree::Draw() methods to deal with -- just clicking on the links makes ROOT hang.
But I can access the contents of the trigger candidates with
 
duneexamples/GalleryScripts/trigdump.C
 
I had to add the dunedetdataformats and dunedaqdataformats include directories to ROOT_INCLUDE_PATH
which I hadn't done before.  I patched the products in CVMFS to do that.
 
Worth giving a try!  You just need the new fcl in duneprototypes and the gallery script in duneexamples in develop
to try it out; Barnali's module was released a few weeks ago and is present in dunesw v09_72_1d00.
 
Tom

[YoannKermaidic]

Hi,

Since I see this issue is still opened, I wonder what the status of the BDE CB runs that were taken in 2022 is?
Are there some long runs (>= 10 min) available for analysis?

Cheers,
Yoann

[wenqiang-gu]

@YoannKermaidic I made a PR to support trigger data in BDE coldbox.