'NoUT' tests still run PrStorePrUTHits

A number of the 'NoUT' Moore tests still seem to run PrStorePrUTHits, which then causes them to fail in the dd4hep builds. e.g.

https://lhcb-nightlies.web.cern.ch/nightly/lhcb-dd4hep/1131/Moore/x86_64_v2-centos7-gcc11%2Bdd4hep-opt/tests#Hlt2Conf.test_hlt2_noUT_trackefflines

https://lhcb-nightlies.web.cern.ch/nightly/lhcb-dd4hep/1131/Moore/x86_64_v2-centos7-gcc11%2Bdd4hep-opt/tests#RecoConf.hlt2_fastest_reco_without_UT_with_mcchecking

https://lhcb-nightlies.web.cern.ch/nightly/lhcb-dd4hep/1131/Moore/x86_64_v2-centos7-gcc11%2Bdd4hep-opt/tests#RecoConf.hlt2_light_reco_pr_kf_velo_open_without_UT_with_mcchecking

https://lhcb-nightlies.web.cern.ch/nightly/lhcb-dd4hep/1131/Moore/x86_64_v2-centos7-gcc11%2Bdd4hep-opt/tests#RecoConf.hlt2_light_reco_pr_kf_without_UT_with_mcchecking

All fail with

198 - PrStorePrUTHits.UTReadoutTool         FATAL UTReadoutTool:: Exception throw: get():: No valid data at '/world/BeforeMagnetRegion/UT:DetElement-Info-IOV' StatusCode=FAILURE
199 - PrStorePrUTHits.UTReadoutTool.sy...   FATAL  Exception with tag= is caught

That issues is tracked in LHCb#217 (closed), but surely a 'NoUT' test shouldn't be trying to run this at all ?

@decianm @cmarinbe FYI

added to epic &1

assigned to @decianm

assigned to @cmarinbe

added RTA WP2 label

added dd4hep label

This is still needed until we have a new training of the GhostProbability (if it is indeed this place you are talking about). We can exclude it "by hand" (meaning, we add an empty producer), but it most likely will make the GhostProbability even less tuned for the no UT scenario. If there is no way to fix the underlying UT problem, then I guess that is the only way.

The problem is given we are not going to be using UT this year, fixing the s/w is probably lower priority than preparing the hardware. So in the short term I think yes, we need remove this completely from the sequence.

What does GhostProbability need from UT ? Note in real data this year it will have nothing, so creating an empty dummy producer for its hits is probably a more realistic representation of that anyway.

Yes, of course, but we were promised no-UT MC a long time ago, and I wanted the GhostProbability retuned without UT so this could be removed. The event multiplicity is used as an input.

Now given this will not happen soon I am afraid, the only way out for now will be an empty producer.

I can make an MR later.

changed the description

mentioned in issue LHCb#217 (closed)

mentioned in merge request Moore!1560 (merged)

@decianm Your MR seems to have helped some tests, such as this one

https://lhcb-nightlies.web.cern.ch/nightly/lhcb-dd4hep/1133/Moore/x86_64_v2-centos7-gcc11%2Bdd4hep-opt/tests#Hlt2Conf.test_hlt2_noUT_trackefflines

which now hits a CALO issue, but some others are still using UT components, such as

https://lhcb-nightlies.web.cern.ch/nightly/lhcb-dd4hep/1133/Moore/x86_64_v2-centos7-gcc11%2Bdd4hep-opt/tests#RecoConf.hlt2_fastest_reco_without_UT_with_mcchecking

https://lhcb-nightlies.web.cern.ch/nightly/lhcb-dd4hep/1133/Moore/x86_64_v2-centos7-gcc11%2Bdd4hep-opt/tests#RecoConf.hlt2_light_reco_pr_kf_velo_open_without_UT_with_mcchecking

https://lhcb-nightlies.web.cern.ch/nightly/lhcb-dd4hep/1133/Moore/x86_64_v2-centos7-gcc11%2Bdd4hep-opt/tests#RecoConf.hlt2_light_reco_pr_kf_without_UT_with_mcchecking

Any idea why your fix isn't working here ?

I assume it's the MC checking that still accesses hits in the back. Let me have a look at it.

The problem is here: https://gitlab.cern.ch/lhcb/Moore/-/blob/master/Hlt/RecoConf/python/RecoConf/mc_checking.py#L74

as it by default matches all hits, no matter if there are actually tracks that have UT hits or not. I'll see if I can easily fix this.

the error with PrStorePrUTHits.UTReadoutTool is appearing again in the test_hlt2_noUT_trackefflines job when including the fixes for the calo in !2936 (merged) , so it seems the tool is called by something else downstream the pipeline. See https://lhcb-nightlies.web.cern.ch/nightly/lhcb-master-mr/4674/Moore/x86_64_v2-centos7-gcc11%2Bdd4hep-opt/tests#Hlt2Conf.test_hlt2_noUT_trackefflines

The hlt2_noUT_trackeff_test options run the DiMuonTrackEfficiency lines, which use, among others, make_downstream_muons and make_muonut_muons (see DiMuonTrackEfficiency), which obviously use UT hits (see probe_muons and make_charged_downstream). The configuration of these lines needs to be fixed to be able to run with the noUT reconstruction. Maybe @rowina as author of the lines can fix it?

@rowina @peilian Is this being addressed in Moore!1616 (merged) ?

No, not yet. I missed this issue somehow. Will take a look and fix it together with one of our open MR.

Fixed in Moore!1567 (merged)

changed the description

mentioned in issue #345 (closed)

mentioned in merge request Moore!1567 (merged)

closed with merge request Moore!1567 (merged)

mentioned in commit Moore@350a6208