Use adapted input file when running Rich test in DD4hep mode

/ci-test lhcb-datapkg/PRConfig!511

added ci-test-triggered label

[2025-02-07 16:11] Validation started with lhcb-master-mr#12502
[2025-02-07 17:22] Validation started with lhcb-master-mr#12508
[2025-03-05 18:24] Validation started with lhcb-sim11-mr#295
[2025-03-05 18:24] Validation started with lhcb-master-mr#12777
[2025-03-06 15:56] Validation started with lhcb-sim11-mr#298
[2025-03-06 15:57] Validation started with lhcb-master-mr#12785
[2025-03-06 20:10] Validation started with lhcb-sim11-mr#299
[2025-03-06 20:11] Validation started with lhcb-master-mr#12795
[2025-03-13 16:04] Validation started with lhcb-master-mr#12876
[2025-03-13 16:26] Validation started with lhcb-sim11-mr#316
[2025-03-14 10:50] Validation started with lhcb-master-mr#12881
[2025-03-14 10:51] Validation started with lhcb-sim11-mr#318
[2025-03-14 14:29] Validation started with lhcb-master-mr#12886
[2025-03-31 15:33] Validation started with lhcb-master-mr#13163
[2025-04-10 18:29] Validation started with lhcb-master-mr#13321

mentioned in merge request Detector!581

added 1 commit

00e52ee0 - Use adapted input file when running Rich test in DD4hep mode

Compare with previous version

added 1 commit

5a220802 - Use adapted input file when running Rich test in DD4hep mode

Compare with previous version

/ci-test lhcb-datapkg/PRConfig!511

Started integration test build. Once done, check the results or the comparison to a reference build.

The latest tests do not seem to use Boole-MR-562. Therefore it has the old configuration, whereby it would run DetDescConfig+'DetailedSim' vs DD4HEPConfig+CopySim. Here 'CopySim' essentially copies the input data into digi format, in order to bypass detailed simulation. Hence the output formats in the old(-) and new(+) are different. (It is possible that using the Boole-MR was not the goal of this particular test by @sponce ).

In any case, my inference is based on the following lines in the output.

...........................

Digi INFO Member list: GaudiSequencer/DigiRichSeq

-DigiRichSeq INFO Member list: Rich::MC::Digi::Signal/RichPDSignal, Rich::MC::Digi::SummedDeposits/RichSummedDeposits, Rich::MC::Digi::DetailedFrontEndResponsePMT/RichPDResponse, Rich::MC::Digi::MCRichDigitsToRawBufferAlg/RichFillRawBuffer, LHCb::UnpackRawEvent/UnpackRawEvent, Rich::Future::RawBankDecoder/RichDecodeTest

+DigiRichSeq INFO Member list: Rich::MC::Digi::Signal/RichPDSignal, Rich::MC::Digi::SummedDeposits/RichSummedDeposits, Rich::MC::Digi::CopySummedDepositsToDigits/RichPDResponse, Rich::MC::Digi::MCRichDigitsToRawBufferAlg/RichFillRawBuffer, LHCb::UnpackRawEvent/UnpackRawEvent, Rich::Future::RawBankDecoder/RichDecodeTest Link INFO Member list: GaudiSequencer/LinkRichSeq .............................................

We need to test without !562. Could you also provide @gcorti with the options to produce a sample similar to the input file you provided so that we document how it is being produced ?

I can attach an example options file used to create the sim file with any other related details in the coming days. It is all quite standard stuff.

However, one may note that the Boole !562 also contains the ‘configuration updates’ to activate the full digitization in DD4HEP for RICH. Without that one would always see this type of mismatch. One good option is to leave this issue as ‘known and expected’.

One may also note that even with !562 activated the outputs will never match between the detdesc and dd4hep versions, because of the differences in RICH geometry-versions, condDB etc., as I mentioned earlier, in related posts, including !562. In addition, the sim file I provided is for min bias whereas the old detdesc ref uses some signal channel created, long time ago.