test-VP 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-VP

assigned to @tlatham

added VP label

I believe that this should already be fixed in !456 (closed) - @hcroft can you confirm?

That MR has been pending for some time since it depends on lhcb-conddb/lhcb-conditions-database!60 (merged), which first requires a new simulation branch to be created.

@tlatham @zexu This is fixed in the updates, but blocked as to write the YAML into the conditions I do not want to mix the "live" detector conditions, where alignments are updated regularly for example. I am waiting for the update to have a simulation branch in the conditions lhcb-conddb/lhcb-conditions-database!60 (merged) I hope this will be resolved soon, but I understand there are issues.

assigned to @hcroft

mentioned in issue #18

added Simulation label

mentioned in merge request !623 (merged)

Hi all, may I bring up the discussion again? It seems that the VP test still does not work with DD4hep. Do you have any plans to fix it? https://lhcb-nightlies.web.cern.ch/nightly/lhcb-sim11-mr/278/Boole/x86_64_v2-el9-gcc13-opt/tests

changed milestone to %Digi17c/2025.04

@mexu Yes that is a bug, we should have conditions and code to read them in a state where the code does not crash if they are missing. I'll try and check soon, but it may be tomorrow before I can get to this now.

wonderful, many thanks!

Thanks for investigating David. I must admit it's a bit mysterious to me, since all the tests ran ok during the ci-tests that were run before all the recent merge requests were merged, so not sure why it's suddenly crashing now.

@mexu @tlatham I think I know what the problem is. The issue is that in Detector compact/components/VP/2024.Q1.2-v00.00/conditions.xml is missing the Simulation.yml link (and the Detector.yml too), which is in compact/components/VP/trunk/conditions.xml and compact/components/VP/2024-v01.00/conditions.xml, so I guess previous test used one of those. I guess I was not expecting 2024.Q1.2 to derive from an "old" version of the conditions (2024-v00.00 is also missing the conditions link which I assume was copied to make the Q1.2 version).

I'll make a MR to fix 2024.Q1.2-v00.00 and all of the branches but I not know what backwards compatibility needs to be maintained.

Thanks David, many thanks for your feedback, I think we have the same problem as UT, I have the same thought on the backwards compatibility, Detector!691 (merged). Let us see how Gloria thinks about that, for me, yes, we should do that.

@hcroft, in VPDigitCreator::initialize we have various protections for the condition not being present, but in VPDepositCreator::initialize those appear to be missing. Would it be sufficient to add such protections also in VPDepositCreator? That way we avoid having to update already-released versions of the geometry.

@tlatham Unfortunately no, it is crashing in VPDigitCreator even with the protections. The fatal error is:

ConditionsDependencyHandler: Failed to resolve conditon:36EA1690C2A1FCF6 @../VP/VPDigitisation/src/VPDigitCreator.cpp:174

where the condition path is missing so the code crashes when creating the condition object, before the tests to determine if the condition is OK can protect it.

I'm working on a MR, but have a bizarre error that LHCb stopped compiling due to a python error in Gaudi:

cmake --build /data/hutchcroft/stack/BooleTest/LHCb/build.x86_64_v2-el9-gcc13-dbg --target all --
...
[845>66>1225/2135] Collecting pytest tests for GaudiConf:GaudiConf.pytest
FAILED: GaudiConf/CMakeFiles/pytest-prefetch-GaudiConf-GaudiConf.pytest /data/hutchcroft/stack/BooleTest/LHCb/build.x86_64_v2-el9-gcc13-dbg/GaudiConf/CMakeFiles/pytest-prefetch-GaudiConf-GaudiConf.pytest
...
E   AttributeError: module 'Gaudi.Configurables' does not have attribute 'Gaudi__Examples__EvtColAlg'

despite neither LHCb or Gaudi having been updated so the code that compiled this morning now does not... Also why is it crashing in LHCb not in Gaudi?

When I can resolve this I'll submit a MR, that way the path exists in all Detector xml files even if the condition is missing in lhcb-conditions-database (I do not plan to change the conditions DB so only Detector).

@mexu @tlatham I've made a MR Detector!694 (merged) which I think resolves the issues. If you are happy with it I can remove the draft tag. It does allow the Boole.boole-VP test to run OK again.

Many thanks @hcroft

mentioned in merge request Detector!694 (merged)

closed with merge request Detector!694 (merged)

mentioned in commit Detector@959a4a3b