Tracking acceptance electrons

[doloresgarcia]

Check duplicate issues.

-Maybe it's related to issue

Goal

I generated Z-->qq (q=uds) events and it look like many electrons don't have tracks. I plot the percentage of electrons that leave a calo cluster but not a track (using truth tracking). The second plot shows the number per bin. Is this expected?

Operating System and Version

..

compiler

..

The version of the key4hep stack

source /cvmfs/sw.hsf.org/key4hep/setup.sh

Package Version

2025_05_26

Reproducer

I generated 3000 events using the code here:
/eos/experiment/fcc/users/m/mgarciam/mlpf/condor/test/data_generation
the result of the data generation is in /eos/experiment/fcc/users/m/mgarciam/mlpf/condor/test/3

Additional context

No response

[Zehvogel]

As far as I understand, you count "the PFO has an attached track" for what you call tracking efficiency here. Can you please split this up into the two contributions: "electron makes a track" and "track gets matched to cluster"?

Previous results for the first part showed efficiency close to 100% while the second part was not studied so much (and is particularly tricky for electrons).

[doloresgarcia]

Hi @Zehvogel , I am not using the PFOs.
I am reconstructing reco clusters and all tracks from using the 'truth' tracking, and these are are the electrons with a reco cluster but no track in the track collection. To say they have no track I check which particle the track is assigned to.

[Zehvogel]

Ok. What I would normally do is start with an MCParticle from the MCParticles collection and check the respective MCTruthSiTracksLink and MCTruthClusterLink, looking for the track and the cluster that this MCParticle contributed the majority of its trackhits/calodepositions to (by parsing the corresponding weight) and then also check the opposite directions (SiTracksMCTruthLink, ClusterMCTruthLink) to see if this MCParticle was the main contributor to the reached track/cluster.

I see that you dropped these two MC to track/cluster link collections from your reco file.
Could you describe in more detail what exactly you are doing to decide whether an MC electron has a track or not?

[Zehvogel]

Also can you plot the efficiency vs. theta of the electron?

[doloresgarcia]

For the tracks I am checking SiTracksMCTruthLink

trk_to_gen_trkidx = sitrack_links["_SiTracksMCTruthLink_from/_SiTracksMCTruthLink_from.index"][iev]
trk_to_gen_genidx = sitrack_links["_SiTracksMCTruthLink_to/_SiTracksMCTruthLink_to.index"][iev]
trk_to_gen_w = sitrack_links["SiTracksMCTruthLink.weight"][iev]

then I assign to each track the particle with the largest weight.
The clusters I build from the calohits using CalohitMCTruthLink in a similar way. I then check which MCs are electrons and have a cluster but no track

[Zehvogel]

Sorry, I can't decipher what the above means. :(
Is that uproot stuff?
What does the / in ["_SiTracksMCTruthLink_from/_SiTracksMCTruthLink_from.index"] do?

Do you parse the weight into its track and cluster components somewhere?
Isn't CaloHitMCTruthLink a relation between calo hits and mcparticles, not clusters? So you check if they made calorimeter hits, not if they made clusters?

[doloresgarcia]

I take the full list so that I don't have to loop over links. Yes, I take he relation between hits and particles and sum the energy of all hits to 'construct' the true cluster.

[doloresgarcia]

I created a simpler script that just checks (SiTracksMCTruthLink, ClusterMCTruthLink) (I attach the script)

test_2.py
I used this file /eos/experiment/fcc/users/m/mgarciam/mlpf/condor/test/7/out_reco_edm4hep_REC.edm4hep.root
Here is the same plot with that script for 3000 events as a function of E and theta

[Zehvogel]

Thx! That is a script that I am able to understand :)

Given that you really take all the existing abs(PDG) == 11 mc particles I am not so surprised about the results at this point.
There are some more selections that need to be done depending on what your goal is.
You certainly want to remove all particles where generatorStatus > 1, these are not seen by the simulation and contain for instance the incoming particles of the collision.
Usually when making these efficiency plots we care about primary electrons i.e. we require that they have generatorStatus == 1. Here you could perform a quick check if you get close to 100% efficiency for these particles.
Now if you are interested in secondary electrons (e.g. for flavour-tag purposes), things become a bit more tricky.
As far as I know, these have generatorStatus == 0and isCreatedInSimulation() == true. For these you probably always want to look at how displaced they are (they can be created very late depending on the process, and there can be many of them). For these it really depends on what exactly you want to do and which ones you need so you might need to parse the MC history a bit more and look at the parents to see if these are "interesting" electrons (e.g. from B, D, K decays) or not (very late photon conversions?).

To summarise:

• If the tracking efficiency for generatorStatus == 1 turns out to be bad in your check we indeed have a new issue
• If it is "only" the efficiency for secondary electrons, I would suggest to make additional plots vs. the distance to the IP at which the particles are created to see if the problem is simply the displacement (Tracking issue for displaced tracks and electron reconstruction efficiency #25). The current performance there is worse than expected even for the ones for which we should have enough hits to make a track. After a certain distance (iirc. 600mm in the barrel) there are just not enough hits to make a track but electrons can still be produced there.

For example here you have just no chance to make a track:

[doloresgarcia]

okay thank you @Zehvogel ! I will check this