Problems with muons using default detector cards

[Jamie Tattersall]

Both the ATLAS and CMS default cards include muons in the 'EFlowMerger'. The EFlowMerger is then used in the jet algorithm step so jets will be formed from muons.

Unfortunately, I think this creates a multitude of problems. Firstly, the scalarHT variable sums jets and muons, so the muon momentum will be double counted.

Secondly, I am not sure that people will realise that this is the default behaviour and will assume that the formed jets are separate (at least I did). In any case, subtracting these jets at a later stage is difficult because the momentum and direction will be changed by any surrounding hadronic activity.

Is there a reason why the muons are not kept as completely distinct objects?

[Michele Selvaggi]

Hi,

you are right, thanks for pointing this out.
all double counting can be avoided by adding to the UniqueObjectFinder the following line, before the line corresponding to jets:

add InputArray MuonIsolation/muons muons

This will give priority to muons with respect to jets.
Indeed then the muon collection you want to book in the TreeWriter is

add Branch UniqueObjectFinder/muons Muon Muon

We will put this line by default in the cards coming in the next releases.

Cheers,

Michele

[Pavel Demin]

We'll also need to replace

  add InputArray MuonIsolation/muons

with

  add InputArray UniqueObjectFinder/muons

in

module Merger ScalarHT

[Jamie Tattersall]

Ok, I haven't looked at how the UniqueObjectFinder? works in detail but I have two potential problems with this.

1) Will it mean that jets that lie close to muons will be killed even if they are hard?

2) Jets lying close to muons will be shifted towards the muon momentum direction and may change the jet forming algorithms if the muon momentum is subtracted from the particular jet.

Why not just remove muons from EFlowMerger?

Cheers,
Jamie

[Michele Selvaggi]

UniqueObjectFinder gives precedence to arrays declared earlier. So, to answer your questions:

1) it means that jets that are too close to a reconstructed isolated muon will be removed
2) not sure I understand what you mean here. Muons are not subtracted from jets.

Why not just remove muons from EFlowMerger?

We don't want do this since jets may contain non isolated muons that we want to account as being part of the jet.

Cheers,
Michele

[Jamie Tattersall]

Thanks for your answers.

I guess the removal or not of muons from jets is an analysis dependent question. For example, I know that many ATLAS susy searches do not include non-isolated muons in a jet.

However, I can easily change this analysis by analysis.

In any case, if this is done, shouldn't the muon reconstruction efficiency be done first since the momentum of unreconstructed muons cannot be added.

Many thanks,
Jamie

[Michele Selvaggi]

Hi,

in principle the efficiency in reconstructing muons is done in two steps.
The first, MuonTrackingEfficiency, already accounts for reconstruction inefficiencies.
Later, on top of the isolation module, another efficiency is applied. This one allows the user to fine-tune the total reconstruction efficiency according to the expected efficiency for the final isolated objects. It should account for residual identification+isolation efficiencies that are not taken into account by the MuonTrackingEfficiency and MuonIsolation modules that you can model a posteriori via some parameterisation.

It is a matter of choice if you believe that the MuonTrackingEfficiency and MuonIsolation module do the job perfectly you can remove it or reduce it to a pt cut. The point is that there can be, for one analysis, several muon reconstruction efficiencies.

Cheers,

Michele

[Jamie Tattersall]

Thanks Michele, I hadn't realised that.

Cheers,
Jamie

[Pavel Demin]

Detector cards with fixed muons flow are available in the new release 3.0.10.