Electrons are not pT ordered

[amagnan]

Checked in data, for example this file, root://gfe02.grid.hep.ph.ic.ac.uk:1097//store/user/ebhal/CHIP_skim_data_2018_for_sync_20191128/EGamma/crab_EGamma_Run2018C-Nano1June2019-v1/191128_181304/0000/tree_51.root

When printing for example : Events->GetEntries("(nElectron==2) && (Electron_pt[0]<Electron_pt[1]) "); (int) 939

As far as we checked, all other objects are rightly ordered by pT.

[amagnan]

PS: checked also on "original" nanoAOD file, for example: root://eoscms//eos/cms/store/data/Run2018C/EGamma/NANOAOD/Nano1June2019-v1/40000/F3767D14-375D-EC49-B17E-8C4A7A226628.root

[peruzzim]

@amagnan I think this is due to the fact that electrons are not re-ordered after applying the scales&smearings corrections. It was a design choice in the beginning, to facilitate synchronization with workflows based on MiniAOD (keeping the same ordering in lepton collections), or one-by-one checks between subsequent NanoAOD versions.

We can consider changing this for the future, would this be better from your point of view? Typically leptons have to be merged (electrons+muons) and reordered according to their pt in the merged collection, this is why it was not seen as a major nuisance in the design.

[amagnan]

@peruzzim thanks a lot for your reply. Yes I think it would make much more sense to have them pT-ordered, as other objects are (jets, muons). I do not understand your argument about merging electrons and muons: from my experience very few analyses would do that ...?!?

[vlimant]

ping / reopen if needed