boole-UT test with DD4hep failed

Nightly test: https://lhcb-nightlies.web.cern.ch/nightly/lhcb-head/3609/Boole/x86_64_v2-centos7-gcc11-opt/tests#Boole_boole-UT

changed title from Boole-UT test with DD4hep failed to boole-UT test with DD4hep failed

assigned to @hawu

Fix is on the way: !476 (merged)

mentioned in issue #18

I believe this has been fixed. Could you please check again?

Thanks for your update, we will it soon

Great! Thanks!

@hawu https://lhcb-nightlies.web.cern.ch/nightly/lhcb-master-mr/8623/Boole/x86_64_v2-centos7-gcc12-opt/tests#Boole_boole-UT

I believe this issue has been understood. Hopefully we can have it fixed in with Detector!395 (merged).

Thanks for your quick response. Is Detector!395 (merged) ready for the integration test?

Yes, I think it's ready for merging.

However, I have the concern that no TestDBFile is compatible with this MR, because UT geometry has changed here.

Thanks

Hi, Thanks for your work. UT passed the ci-test with Detector!395 (merged) Lbcom!678 (closed). I will close this issue once these two MRs are merged.

Lbcom!667 (merged) includes Lbcom!678 (closed), so Lbcom!678 (closed) is no longer needed and I have closed it.

added Simulation UT labels

mentioned in merge request Detector!395 (merged)

Hi @hawu , sorry to bring up this discussion again, but the UT test still crashes with DD4hep. https://lhcb-nightlies.web.cern.ch/nightly/lhcb-sim11-mr/278/Boole/x86_64_v2-el9-gcc13-dbg/tests

I recall, with everything in master branch and using the sim10/run3-ideal, this test runs fine for me. I will make a new stack and check again. It looks like the reference build is already failing on this test. Which branches are used in the ref test, are they also just master?

Okay master also does not work for me. I will investigate.

it used run3/2024.Q1.2-v00.00 for geometry and sim10/run3-ideal for condition

Looks to me the conditions are not loaded before the construction of DeUT object. The crash happens when trying to read any of this unloaded conditions. Usually I confirm the loading of conditions by looking in the output message for a series of ConditionsLoader lines, which indicate the loaded files, the number of entries per condition, and the run number range. This does not happen before the crash. I find other failed Boole test, such as boole-VP.qmt, does not have this table as well. Could it be somehow the verbosity is turned down, so the table does not print? If this is not the case, I think the not loading the condition is the culprit.

I'm referring to the following ConditionsLoader lines. They are not present in the failed tests.

ConditionsLoader                       INFO ++ Added    3 conditions from Conditions/UT/Alignment/Global.yml               to pool [309590-309590] [  0.615 sec]
ConditionsLoader                       INFO ++ Added    8 conditions from Conditions/UT/Alignment/HalfLayers.yml           to pool [309590-309590] [  0.626 sec]
ConditionsLoader                       INFO ++ Added  968 conditions from Conditions/UT/Alignment/Modules.yml              to pool [309590-309590] [  0.692 sec]
ConditionsLoader                       INFO ++ Added  204 conditions from Conditions/UT/Alignment/Staves.yml               to pool [309590-309590] [  0.643 sec]
ConditionsMgr                          INFO Created IOV Pool for:run(0):[304425-9223372036854775807]
ConditionsLoader                       INFO ++ Added    1 conditions from Conditions/UT/ChannelInfo/NoiseValues.yml        to pool [304425-inf   ] [  0.002 sec]
ConditionsLoader                       INFO ++ Added    1 conditions from Conditions/UT/ChannelInfo/ReadoutSectors.yml     to pool [304425-inf   ] [  0.001 sec]

Is the absence of above ConditionsLoader lines an expected behavior?

Maybe you can change the output level locally to take a look? I am not very familiar with Boole, but I hope the below lines work for that

MessageSvc().OutputLevel = DEBUG 
Boole().OutputLevel = DEBUG

Thanks for the suggestion! I didn't know they belong to DEBUG level in this test. I can confirm the ConditionsLoader works fine.

Then the culprit is missing an entry in UT/2024-v00.00/conditions.xml. Basically the PedestalValues is missing there, which causes this crash. The fix will be trivial, but am I allowed to change UT/2024-v00.00?

changed milestone to %Digi17c/2025.04

created branch 15-boole-ut-test-with-dd4hep-failed to address this issue

mentioned in merge request Detector!691 (merged)

closed with merge request Detector!691 (merged)

mentioned in commit Detector@b0831978