Fix: Allow matching to only primary particles

[bschmookler]

Briefly, what does this PR introduce?

In current main branch, it is possible to match a reconstructed track to a secondary particle with generatorStatus==0. An example where this incorrectly happens can be seen below.

What kind of change does this PR introduce?

• [x ] Bug fix (issue #__)
• New feature (issue #__)
• Documentation update
• Other: __

Please check if this PR fulfills the following:

• Tests for the changes have been added
• Documentation has been added / updated
• Changes have been communicated to collaborators

Does this PR introduce breaking changes? What changes might users need to make to their code?

Does this PR change default behavior?

Yes, for matching of ReconstructedChargedParticles and ReconstructedSeededChargedParticles

[github-actions]

Capybara summary for PR 1356

• rec_dis_10x100_minQ2=1000_craterlake
• rec_dis_10x100_minQ2=1_craterlake
• rec_dis_18x275_minQ2=1000_craterlake
• rec_dis_18x275_minQ2=1_craterlake
• rec_dis_5x41_minQ2=1_craterlake
• rec_e_1GeV_20GeV_craterlake
• rec_pi_1GeV_20GeV_craterlake
  ^{_{Last updated 2024-03-30T01:03+00:00 0ea5396}}

[veprbl]

I was waiting for someone else to response. My first thought that, indeed, generatorStatus==0 is a secondary particle, but I'm not convinced that this is unwanted. The comment/printout can be corrected, for sure.

I wasn't able to understand your screenshots, second one mentions index 34, but the first one has ~20 particles. I suspect, they were taken from different events.

[veprbl]

It could be that the primaries should somehow take priority, but that's not what you suggest.

[bschmookler]

Hi Dmitry. Thanks.

Yeah, thinking about it, I agree that do this 'geometric' matching to charged particles created in the tracking volume makes sense (e.g. a electron-positron pair created by a conversion photon.)

In the screenshots above, I used the TTree::Show(...) method, which I guess truncates some of the printed output. Let me show another event in a different way.

For event 22 in my file:

root [15] events->Scan("ReconstructedSeededChargedParticleAssociations.simID","Entry$==22")
***********************************
*    Row   * Instance * Reconstru *
***********************************
*       22 *        0 *         2 *
*       22 *        1 *        36 *
***********************************

There are 2 matched particles. If I plot the generator status, PDG ID, total momentum, and the r and z of the creation point, I see this for the matched particle 1:

events->Scan("MCParticles.generatorStatus[2]:MCParticles.PDG[2]:std::hypot(MCParticles.momentum.x[2],MCParticles.momentum.y[2],MCParticles.momentum.z[2]):std::hypot(MCParticles.vertex.x[2],MCParticles.vertex.y[2]):MCParticles.vertex.z[2]","Entry$==22")
************************************************************************
*    Row   * MCParticl * MCParticl * std::hypo * std::hypo * MCParticl *
************************************************************************
*       22 *         1 *        11 * 5.3219824 * 0.0448534 * 10.682283 *
************************************************************************

and this for the matched particle 2:

events->Scan("MCParticles.generatorStatus[36]:MCParticles.PDG[36]:std::hypot(MCParticles.momentum.x[36],MCParticles.momentum.y[36],MCParticles.momentum.z[36]):std::hypot(MCParticles.vertex.x[36],MCParticles.vertex.y[36]):MCParticles.vertex.z[36]","Entry$==22")
************************************************************************
*    Row   * MCParticl * MCParticl * std::hypo * std::hypo * MCParticl *
************************************************************************
*       22 *         0 *        11 * 0.1125881 * 829.46469 * -1488.119 *
************************************************************************

You can see that the second particle is created at r = 830mm and z = 1488mm, which is outside the outer barrel MPGD layer.

[veprbl]

I think, we need to implement a different algorithm in place of this one. It could determine leading MCParticle by looking up Track -> Measurement2D -> TrackerHit.

[veprbl]

A workaround for your problem might be to check the DCA from MC vertex to the track.