Neutral Pileup Subtraction

[Jake]

Hi,

I'm clustering jets using the particle flow algorithm and I just have a quick question about the neutral pileup subtraction in this case. The default method in the ATLAS card (which I'm using) is to estimate rho from the total deposition in the calorimeters, using Calorimeter/towers, but I believe this corresponds to the default case where jets are clustered from the same towers.

If I'm clustering using particle flow jets, I believe I should be using the calorimeter energy deposition based on the particle flow algorithm, using Calorimeter/eflowPhotons and Calorimeter/eflowNeutralHadrons to estimate rho. Is this correct, or should Calorimeter/towers be used in this case as well?

Thanks

[Michele Selvaggi]

Yes, you should the same input collection for jet clustering and for PU subtraction to be consistent.
The most optimal is actually to subtract Charged Hadrons that come from PU vertices before hand.
Have a look at this card and look for CHS (ie Charged Hadron Subtracted)

​https://github.com/delphes/delphes/blob/master/cards/CMS_PhaseII/CMS_PhaseII_200PU_v03.tcl

[Jake]

Thanks a lot for your quick response. I'm a little confused about why the module RecoPuFilter is needed. It removes object with tag IsRecoPU=1, but it seems to me that TrackPileUpSubtractor already removes these.

Furthermore, I'm confused why the input to RecoPuFilter in this card is HCal/eflowTracks instead of TrackPileUpSubtractor/eflowTracks. Looking at TrackPileUpSubtractor, it appears that IsRecoPU is set in this module, so taking an input from HCal into RecoPuFilter wouldn't have an effect anyway?

Thanks for your time.

[Michele Selvaggi]

No, the TrackPileUpSubtractor only flags as isRecoPU tracks that come from pile-up.
It is a bit confusing indeed but the TrackPileUpSubtractor only alters existing collection, so that the RecoPuFilter acting on HCal/eflowTracks is fine if TrackPileUpSubtractor was called before.

[Jake]

Thank you for the clarification. What I understand from your response is that if RecoPuFilter is not called then pileup will be tagged by TrackPileUpSubtractor but it will not be removed?

However I don't observe this to be the case. I generated a small sample of events, set up the RecoPuFilter module as above, and output the tracks after the calorimeter, after the TrackPileUpSubtractor, and after the RecoPuFilter. What I observe is that the calorimeter produces 200000 eflowTracks, the TrackPileUpSubtractor reduces this to about 6500 tracks, and the RecoPuFilter produces the exact same collection of tracks as the TrackPileUpSubtractor. I've attached my card and the collection of events in case you'd like to take a look.