Skip to content

MuonCreatorTool - Fix MS vs ID ambiguity

Johannes Junggeburth requested to merge jojungge/athena:AmbiSolver_EndCap into master

Hi everybody,

this MR addresses the ambiguity solving issue in the latest run 3 samples. For instance, the first and the third muon are exactly the same tracks but with the difference that the former comes from the combined chain and the latter is from the MS reconstruction chain only.

*************************************************************************************************************************************
*    Row   * Instance *  muons_pt * muons_eta * muons_phi * muons_aut * muons_all * METracks_ * METracks_ * METracks_ * MSTracks_ * MSTracks_ * MSTracks_ * MSOETrack * MSOETrack * MSOETrack *
***********************************************************************************************************************************************************************************************
*        1 *        0 * 47.143112 * -1.833580 * 0.3412216 *         1 *       326 * 47.484432 * -1.833951 * 0.3407536 *   46.2584 * -1.836207 * 0.3475568 * 47.664672 * -1.836216 * 0.3417955 *
*        1 *        1 * 39.800731 * -2.530924 * -2.153694 *         1 *       342 * 39.844101 * -2.531168 * -2.155760 * 38.721443 * -2.535470 * -2.161242 * 39.610546 * -2.534152 * -2.156061 *
*        1 *        2 * 47.664669 * -1.836216 * 0.3417955 *         5 *        32 * 47.664672 * -1.836216 * 0.3417955 * 16581.949 * -2.483056 * -2.144304 *           *           *           *
*        1 *        3 * 43.126079 * -2.531895 * -2.155912 *         5 *      4128 * 43.126079 * -2.531895 * -2.155912 * 30390.031 * -1.860270 * 0.3478391 *           *           *           *
*        1 *        4 * 44.452144 * -1.834180 * 0.3409264 *         5 *      4128 * 44.452144 * -1.834180 * 0.3409264 *           *           *           *           *           *           *

Note that the muon appears a third time, but this overlap is actually intended as the momentum is reconstructed using only the EM & EO stations. Let me ping here explicitly @pmogg, @atsiamis to ensure that they reject muons having the xAD::Muon::Comissioning author from their samples or that they open a dedicated category in the validation. Anyway, the standard ambiguity solver does somehow no longer resolve this ambiguity. So, I remove by hand the muonCandidates which are used by the MuidCo chain. Eventhough, STACO can also reconstruct the same muon it is ranked at the last place, and the MuidSA track should be kept in favour of STACO. After the fix the same event dump becomes:

*        2 *        0 * 47.143112 * -1.833580 * 0.3412216 *         1 *       262 * 47.484432 * -1.833951 * 0.3407536 *   46.2584 * -1.836207 * 0.3475568 * 47.664672 * -1.836216 * 0.3417955 *
*        2 *        1 * 39.800731 * -2.530924 * -2.153694 *         1 *       262 * 39.844101 * -2.531168 * -2.155760 * 38.721443 * -2.535470 * -2.161242 * 39.610546 * -2.534152 * -2.156061 *
*        2 *        2 * 43.126079 * -2.531895 * -2.155912 *         5 *      4128 * 43.126079 * -2.531895 * -2.155912 * 16581.949 * -2.483056 * -2.144304 *           *           *           *
*        2 *        3 * 44.452144 * -1.834180 * 0.3409264 *         5 *      4128 * 44.452144 * -1.834180 * 0.3409264 * 30390.031 * -1.860270 * 0.3478391 *          *           *           *

Let me also mention that the unmatched efficiencies can exceed one if we have a sample with many close-by STACO / MuidSA muons. May be it is better to break down this efficiency into each muon author. But that mainly addresses ATLASMCP-111

Addresses ATLASRECTS-6748

Merge request reports