[DD4Hep] make sure that expectations for retrieving a numeric value are met

[ianna]

PR description:

Force a request to get a numeric value for a non-evaluated numeric value to fail.

This will allow us to trace all cases where XML may need an update without debugging the C++ code.
See #32414

PR validation:

if this PR is a backport please specify the original PR and why you need to backport that PR:

Before submitting your pull requests, make sure you followed this checklist:

• verify that the PR is really intended for the chosen branch
• verify that changes follow CMS Naming, Coding, And Style Rules
• verify that the PR passes the basic test procedure suggested in the CMSSW PR instructions

[ianna]

please test

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-32422/20288

• This PR adds an extra 16KB to repository

[cmsbuild]

A new Pull Request was created by @ianna (Ianna Osborne) for master.

It involves the following packages:

DetectorDescription/DDCMS

@civanch, @Dr15Jones, @makortel, @cvuosalo, @ianna, @mdhildreth can you please review it and eventually sign? Thanks.
@fabiocos, @slomeo, @vargasa this is something you requested to watch as well.
@silviodonato, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

[cmsbuild]

-1

CMSSW: CMSSW_11_3_X_2020-12-08-1100
SCRAM_ARCH: slc7_amd64_gcc900
You can see the results of the tests here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-c0a02f/11436/summary.html

I found follow errors while testing this PR

Failed tests: RelVals

• RelVals:

When I ran the RelVals I found an error in the following workflows:
11624.911 step2

runTheMatrix-results/11624.911_TTbar_13+2021_DD4hep+TTbar_13TeV_TuneCUETP8M1_GenSim+Digi+Reco+HARVEST+ALCA/step2_TTbar_13+2021_DD4hep+TTbar_13TeV_TuneCUETP8M1_GenSim+Digi+Reco+HARVEST+ALCA.log

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-32422/20297

• This PR adds an extra 16KB to repository

[cmsbuild]

Pull request #32422 was updated. @civanch, @Dr15Jones, @makortel, @cvuosalo, @ianna, @mdhildreth, @cmsbuild can you please check and sign again.

[ianna]

please test

[cmsbuild]

-1

CMSSW: CMSSW_11_3_X_2020-12-08-2300/slc7_amd64_gcc900
You can see the results of the tests here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-c0a02f/11452/summary.html

I found follow errors while testing this PR

Failed tests: RelVals

• RelVals:

When I ran the RelVals I found an error in the following workflows:
11624.911 step1

runTheMatrix-results/11624.911_TTbar_13+2021_DD4hep+TTbar_13TeV_TuneCUETP8M1_GenSim+Digi+Reco+HARVEST+ALCA/step1_TTbar_13+2021_DD4hep+TTbar_13TeV_TuneCUETP8M1_GenSim+Digi+Reco+HARVEST+ALCA.log

[cvuosalo]

@ghugo83 Did you see the error in this PR test?
"Request for a non-existent numeric parameter PixelROCRows Please, check that it is defined in XML and has an eval attribute set." It's related to TrackerGeometricDetESModule/trackerNumberingGeometry. Are you working on this?

[ianna]

Legacy DD returns zero by design. It looks like current Tracker code needs this feature to construct a generic GeomDet. It's possible that the other sub-detectors exploit it as well. Closing the PR for now.

[ghugo83]

@ghugo83 Did you see the error in this PR test?
"Request for a non-existent numeric parameter PixelROCRows Please, check that it is defined in XML and has an eval attribute set." It's related to TrackerGeometricDetESModule/trackerNumberingGeometry. Are you working on this?

Well, seeing this first with this message ;)
So I have looked at it, and there are plenty of numerical values in the XMLs (both Phase 1 and Phase 2) with are not set with eval = true. This had correct behavior with old DD, but also with DD4hep until recently (trackerRadLength/Xi, numROCRows, were for sure OK for example with DD4hep workflow).
So there must have been a very recent change in FilteredView behavior, that now makes these 'eval=true' needed in the XMLs ? If so, I will just add it to all the XMLs (but would rather not use versions as numerous files are concerned).

[ianna]

@ghugo83 Did you see the error in this PR test?
"Request for a non-existent numeric parameter PixelROCRows Please, check that it is defined in XML and has an eval attribute set." It's related to TrackerGeometricDetESModule/trackerNumberingGeometry. Are you working on this?

Well, seeing this first with this message ;)
So I have looked at it, and there are plenty of numerical values in the XMLs (both Phase 1 and Phase 2) with are not set with eval = true. This had correct behavior with old DD, but also with DD4hep until recently (trackerRadLength/Xi, numROCRows, were for sure OK for example with DD4hep workflow).
So there must have been a very recent change in FilteredView behavior, that now makes these 'eval=true' needed in the XMLs ? If so, I will just add it to all the XMLs (but would rather not use versions as numerous files are concerned).

Yes, it was introduced in the two recent PRs we've discussed at the last meeting that have fixed the thread safety issue:
#32249

[ianna]

@ghugo83 - here is the issue that is still open: #32414

[ghugo83]

@ianna Thanks