Fork me on GitHub

Opened 9 years ago

Last modified 9 years ago

#885 new Bug

Isolation via fUniqueID

Reported by: Keith Pedersen Owned by:
Priority: major Milestone:
Component: Delphes code Version: Delphes 3
Keywords: Isolation fUniqueID electron lepton Cc:

Description

Hello,

The fUniqueID comparison for Isolation no longer works for electrons when IsolationInputArray = EFlowMerger/eflow.

Let me know if I correctly understand the new eflowTrack procedure (Calorimeter lines 562--604). Previously, Calorimeter would just pass the track pointers through (and it still does for muons), but it's creating clones for electrons and pions. For well-resolved tracks, it creates exact clones and subtracts their energy from the tower. After well-resolved tracks have been subtracted, whatever tower energy remains is then equi-partitioned among the poorly resolved tracks. Only if there are no poorly resolved tracks does it create an eflow tower.

If I've got this right, then any electrons which show up in eflowTracks are clones of the original smeared tracks (with a different fUniqueID). If the original smeared tracks is used for Isolation's CandidateInputArray (which is generally the case), while eflowTracks are used for IsolationInputArray, the same electron will not have the same fUniqueID in both arrays, and will exclude itself.

My local/temporary fix is to merge TrackMerger/tracks with the neutral eflow objects to create the IsolationInputArray.

Also, after examining the conditional structure of Calorimeter lines 406--437, I'm curious. Was it intended to keep tracks with a cal fraction like {0.6 0.4} out of eflowTracks entirely?

Cheers,
Keith

Change History (2)

comment:1 by Michele Selvaggi, 9 years ago

Hi Keith,

thanks for examining the code so carefully.
which version of Delphes and card are you using?
If you have a look at the CMS card, we now extract electrons precisely from the eflow collection (via the ElectronFilter) so that the fUniqueID is the same between the two collections when testing the isolation.

Concerning your second point, it was intended to keep out of eflow mixed ECAL/HCAL deposits for now, given that no charged particle have such properties in our default cards (although in real life indeed charged pions deposit in both). It is something we wanted to address later.

Michele

comment:2 by Keith Pedersen, 9 years ago

Michelle,

Thanks for your quick response; I was not aware of this change in methodology.

I am using Delphes 3.3.0 with <delphes_card_ATLAS.tcl>. This card still uses eflow for isolation, which is what caused my problem.

Keith

Note: See TracTickets for help on using tickets.