Muon detector element returns wrong or invalid positions

The positions of many muon tiles seems to be wrong when running with DD4hep and also when comparing to DetDesc. For some tiles, positions with nan or 0 are returned. Details of a run with DD4hep where exceptions are caught can be seen in the attached log file: allen_muon_dd4hep.log. For example:

DumpMuonTable                         ERROR bad position for stripX, tile 46237185 S1(48,2)Q0,R2,48,1, gridX = 48, gridY = 2 bad numeric conversion: positive overflow
DumpMuonTable                         ERROR bad position for stripX, tile 46237217 S1(48,2)Q0,R2,49,1, gridX = 48, gridY = 2 bad numeric conversion: positive overflow
DumpMuonTable                         ERROR bad position for stripX, tile 46237249 S1(48,2)Q0,R2,50,1, gridX = 48, gridY = 2 bad numeric conversion: positive overflow
DumpMuonTable                         ERROR bad position for stripX, tile 46237281 S1(48,2)Q0,R2,51,1, gridX = 48, gridY = 2 bad numeric conversion: positive overflow
DumpMuonTable                         ERROR bad position for stripX, tile 46237313 S1(48,2)Q0,R2,52,1, gridX = 48, gridY = 2 bad numeric conversion: positive overflow

As a result of this, the HLT1 muon decoding cannot currently initialize with DD4hep. Even if that is fixed by catching exceptions the result cannot be trusted.

The lookup tables that are created for the HLT1 muon decoding contain the positions of all pads and strips. To allow easy comparison of these tables between DetDesc and DD4hep builds, I've added some code to the geometry converters that feed the HLT1 muon reconstruction; please see Allen!1028 (closed) (which is not to be merged). The respective branch can be used to recreate the json files to test fixes.

These tarballs (extract with Jxf) contain the json files for the DetDesc and DD4hep builds:

• allen_muon_detdesc.tar.xz
• allen_muon_dd4hep.tar.xz

To recreate these files, build the branch of Allen!1028 (closed) with DetDesc and DD4hep and run:

for DetDesc:

$> ./MooreOnline/run bash --norc 
$> python ./Allen/Dumpers/BinaryDumpers/options/allen.py --real-data --tags="upgrade/master,upgrade/md_VP_SciFi_macromicrosurvey" --mep root://eoslhcb.cern.ch///eos/lhcb/wg/rta/samples/data/247547-LHCb-MEP/bu_247547_BU_0000.mep -t 4 -s 8 --events-per-slice 1000  --sequence=${ALLEN_INSTALL_DIR}/constants/hlt1_pp_matching_veloSP.json --enable-run-changes -n 10000

for DD4hep:

$> ./MooreOnline/run bash --norc 
$> python ./Allen/Dumpers/BinaryDumpers/options/allen.py --real-data --tags="master,master" --mep root://eoslhcb.cern.ch///eos/lhcb/wg/rta/samples/data/247547-LHCb-MEP/bu_247547_BU_0000.mep -t 4 -s 8 --events-per-slice 1000  --sequence=${ALLEN_INSTALL_DIR}/constants/hlt1_pp_matching_veloSP.json --enable-run-changes -n 10000

Please note that LHCb::MuonUpgrade::ComputeTilePosition is doing something very similar and is used in the Moore CPU decoding algorithm: MuonRawInUpgradeToHits. It probably suffers the same consequences. Exceptions are not thrown there, because nothing is done with the numbers that are obtained from DeMuon. In DumpMuonTable in Allen some calls to boost::numeric_cast<float> are used, which throw the exceptions listed above.

FYI @jonrob @gligorov @samarian

assigned to @desimone, @farchill, and @rvazquez

changed the description

Doing god's work @raaij

mentioned in merge request !300 (merged)

With the latest commit the exceptions are gone, thanks @farchill.

I've created and attached new JSON files and there are still many differences in coordinates and pad sizes, for example with DetDesc I see:

| DetDesc stripX_tiles    | DD4Hep stripX_tiles     |
| ------------------------| ----------------------- |
| "S0(48,1)Q0,R0,0,1": [  | "S0(48,1)Q0,R0,0,1": [  |
|     7.4083333015441895, |     82.80416870117188,  |
|     377.6252136230469,  |     377.6252136230469,  |
|     15205.359375,       |     15105.359375,       |
|     3.2083332538604736, |     1.6041666269302368, |
|     126.27854919433594, |     63.13927459716797,  |
|     33.95494842529297   |     16.977474212646484  |
| ],                      | ],                      |
| "S0(48,1)Q0,R0,1,1": [  | "S0(48,1)Q0,R0,1,1": [  |
|     13.824999809265137, |     86.01249694824219,  |
|     377.6252136230469,  |     377.6252136230469,  |
|     15205.359375,       |     15105.359375,       |
|     3.2083332538604736, |     1.6041666269302368, |
|     126.27854919433594, |     63.13927459716797,  |
|     33.95494842529297   |     16.977474212646484  |
| ],                      | ],                      |

For each pad entry the numbers are (x, y, z, dx, dy, dz). It looks like for these tiles x is wrong in dd4hep, y is correct, z is close and dx, dy and dz are off by a factor 2.

allen_muon_dd4hep.tar.xz

I guess the factor 2 on DX,DY,DZ is due to the way the sensitive area is defined for the gaps in dd4hep. I have erroneously added a 0.5 factor on top of the values as it was in detdesc. Concerning Z, @desimone @bcouturi and @tlatham are already investigating this issue. No clue about X, I'll try to dig in the code and let you know as soon as I find something.

See comment !300 (comment 6091827)

Let's move the discussion to the MR and then this issue can be closed once things are resolved.

Can this be closed now?

repin @farchill and @raaij , could you please kindly confirm if this issue can be closed or not? Looks like the things mentiond in this issue has been addressed.