Label for raw::RDStatus

[wenqiang-gu]

Hi @dladams , in the DataPrepModule_module.cc, the raw::RDStatus is retrieved with a label "m_DigitProducer:m_DigitName".

art::InputTag itag2(m_DigitProducer, m_DigitName);
auto hstats = evt.getHandle<std::vector<raw::RDStatus>>(itag2);

However, for VD coldbox CRP2 & CRP3, the correct label is only "m_DigitName" ("daq").

PROCESS NAME.. | MODULE LABEL.... | PRODUCT INSTANCE NAME | DATA PRODUCT TYPE......................... | SIZE
CRP2CBDataReco | daq............. | ..................... | std::vector<raw::RDStatus>................ | ...1
CRP2CBDataReco | tpcrawdecoder... | daq.................. | std::vector<raw::RawDigit>................ | 3072

Could you update it with an alternative label? Such as a configurable parameter?

[dladams]

I am looking in to this now.

[dladams]

Ar you saying that for CRP2+ data, we should construct the art::InputTag with only one argument or leave the first blank, or...?

Or do we need help from the artists?

[wenqiang-gu]

Is the DataPrepModule_module.cc supposed to also work for all other detectors?
For VD CRP2 & 3, we should construct the art::InputTag with only one argument ("daq"). So it would work if we can add one more configurable parameter in addition to "DigitLabel". For example, "RDStatusLabel"?

[dladams]

The module was written before we had CRPs. I would like to merge to two modules we have now and make them work for all cases including #20 and more. Whatever hack we make here to make this work for the coldbox should be a step in that direction.

There are two labels: producer and name with config param for each: DigitProducer and DigitName. These are used to retrieve both RawDigit and RDStatus. I understand that for CRP:

1. We need different labels for RawDigit and RDStatus
2. for RDStatus, we only use the name

Is this correct? Assuming yes, I would make these changes:

1. Add optional config parameters StatusProducer and StatusName.
2. Use the values for DigitProducer and DigitName if these are omitted (for backward compatibility).
3. Use StatusProducer and StatusName (instead of DigitProducer and DigitName now) to retrieve the RDStatus.
4. In either case, if XXXProducer is blank, construct art::InputTag with only XXXName.

Is this what we want to do?

[wenqiang-gu]

Hi @dladams , the proposal sounds good to me.

[dladams]

Looking more carefully at the code, I see that instead of DigitProducer and DigitName, the old module has a parameter DigitLabel which is interpreted as producer:name if a colon is present or producer with name blank if there is no colon.

The new version adds StatusLabel with the same convention plus the special values:

• "none" to not open the RDStatus container
• "same-as-digit" to use the same vlaues as the digit container.

The default value for StatusLabel is the last.

Also, I see the existing code always uses itag2(producer, name) to open the digit container with name blank if the configuration does not provide it (no colon in label). I do the same for the RDStatus in the new code.

[dladams]

I have pushed the above changes to the develop branch of dunedataprep. I assume we already have build tests that will notice if the changes break the processing of protoDUNE and other existing config. Please let me know if there are any problems there.

Adding

StatusLabel: "daq"

to the present configuration should allow you to process the CRP2+ data. Again please let me know if there are problems there.

I did run the suite of component tests and the fcl test:

duneproc> duneTestFcl 
iceberg3_decode_reco.fcl is ok
iceberg4a_decode_reco.fcl is ok
iceberg4b_decode_reco.fcl is ok
iceberg5_decode_reco.fcl is ok
standard_reco_dune10kt_nu_1x2x6.fcl is ok
vdcoldbox_raw_dataprep.fcl is ok
vdcoldbox_raw_tdedataprep.fcl is ok
hdcoldbox_raw_dataprep.fcl is ok
protodune_dqm.fcl is ok
protodune_dqm2.fcl is ok
iceberg3_dqm1.fcl is ok
iceberg4_dqm1.fcl is ok
iceberg5cond_dqm1.fcl is ok
crp2cb_data_jul2022_reco.fcl is ok
crp3cb_data_oct2022_reco.fcl is ok
All 15 fcl files processed successfully.

All tests pass.

Should we now be using a different fcl for the crp tests?

Please LMK or close this report if it appears all is OK.

[wenqiang-gu]

Thank you! This works for CRP tests now. I have updated the configuration in dunesw.