RICH1 : numbering scheme update for Mapmt modules

Recently it was discovered that an update is needed in the numbering of the Rich1 Mapmt modules. This update is implemented here. The related details from hardware are available in a recently created EDMS document https://edms.cern.ch/document/2741320 . The effect of this update is a rotation of each column of modules by 180 degrees. In addition the modules at the corners which are farthest away from the beamline, have no ECR.

Requires LHCb!3598 (merged) Rec!2925 (merged)

assigned to @bcouturi

added 1 commit

• 90143716 - updated checksums for geometry updates in Rich1 Mapmt Numbering scheme update

Compare with previous version

added 11 commits

• 90143716...c80f5e8d - 8 commits from branch master
• a809a9a3 - Rich1 Mapmt Numbering scheme Update in May25-2022
• 87afba0c - Fixed formatting
• a9a9678c - updated checksums for geometry updates in Rich1 Mapmt Numbering scheme update

Compare with previous version

resolved all threads

resolved all threads

added 1 commit

• fa2d4c8c - No need to specify type twice

Compare with previous version

BTW, Chris, This is already wrt latest master; however, it seems some of the commits today are already merged (166 I think) I guessing this does not cause any problems.

resolved all threads

resolved all threads

resolved all threads

@seaso This MR will, of course, break support for the latest SIM samples I am testing against.

@bcouturi @clemenci I presume its possible with Detector to support multiple geometries, even if this is not something we have done yet ? How difficult would it be to make a 'tag' (or however it is done) of Detector with the current master geometry, such that I can carry on using that tag to test the performance against current DetDesc generated sim samples, such as I do in

https://lhcb-nightlies.web.cern.ch/nightly/lhcb-master/1692/Rec/x86_64_v2-centos7-gcc11%2Bdd4hep-opt/tests#RichFutureRecSys.pmts-v3.reco-from-dst

but then commit the changes here to master so they can be tested against real data / future dd4hep MC samples ? I presume at some point in the future we will need the ability to support multiple geometries in Detector ?

@jonrob the normal way would be to keep a specific version of the trunk directory with the compatible code.

added 2 commits

• b78069be - Add compact/before-rich1-geom-update-26052022 that contains a geometry from...
• 75b6c8a8 - Changes to support old RICH1 geometry as well as update in trunk

Compare with previous version

mentioned in merge request LHCb!3598 (merged)

changed the description

mentioned in merge request Rec!2925 (merged)

changed the description

added RICH label

mentioned in merge request !206 (merged)

mentioned in issue #27

resolved all threads

marked this merge request as ready

/ci-test --merge LHCb!3598 (merged) Rec!2925 (merged)

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

Throughput Test Moore_hlt2_fastest_reco: 505.4 Events/s -- change of 0.17% vs. reference

Throughput Test Moore_hlt2_pp_thor: 295.6 Events/s -- change of 0.08% vs. reference

Throughput Test Moore_hlt1_pp_default: 28411.9 Events/s -- change of -0.20% vs. reference

added ci-test-triggered label

• [2022-05-27 11:47] Validation started with lhcb-master-mr#4548

merged

mentioned in commit 3f3ea769

mentioned in issue Moore#444 (closed)