Fork me on GitHub

Opened 10 years ago

Last modified 10 years ago

#312 new Bug

Muons get lost by analyzing

Reported by: Maximilian Heindl Owned by:
Priority: critical Milestone:
Component: Delphes code Version: Delphes 3
Keywords: Cc:

Description

Dear experts,

I'm using Delphes3 to simulate events created with Pythia (some Leptoquark samples, that I attach).

I modified the original delphes-card for ATLAS, in order to fit it to my needs (very little changes).

When I analyze the output of Delphes it with ROOT (following the examples that you put in the "README"), I have the impression that something is not working.

There are some events where Delphes reconstruct only one muon. For those events I looked at the event-displays. The event-displays show indeed two high-pt muons in those events where the root analysis shows only one.

Could you help with that?

I'm attaching the Delphes card and the hepmc input, as well as the root output of delphes.

Some events where I notice this behaviour are:
30, 46, 60

In case you want to have a look, I'm also attaching my analysis script.

With best regards,
Maximilian

Attachments (3)

testDelphes.C (2.3 KB ) - added by Maximilian Heindl 10 years ago.
analysis script
delphes_card_ATLAS_NoIso2.tcl (18.2 KB ) - added by Maximilian Heindl 10 years ago.
delphes card (modified a little bit by me)
event60.png (154.9 KB ) - added by Maximilian Heindl 10 years ago.
event display

Download all attachments as: .zip

Change History (5)

by Maximilian Heindl, 10 years ago

Attachment: testDelphes.C added

analysis script

by Maximilian Heindl, 10 years ago

delphes card (modified a little bit by me)

by Maximilian Heindl, 10 years ago

Attachment: event60.png added

event display

comment:1 by Maximilian Heindl, 10 years ago

Since the hepmc and the output root file were too big, I copied them in a public area:

/afs/cern.ch/user/s/siragusa/public/LQ700.hepmc
/afs/cern.ch/user/s/siragusa/public/LQ700NoIso2.root

Thanks!

comment:2 by Michele Selvaggi, 10 years ago

Hi Maximilian,

What is likely to have happened, is some of these muons are in the jet collection, because they fail to pass the isolation criteria.
This is what the UniqueObjectFinder module does. It sets a higher priority to collection being called first.

So for instance, if you have:

module UniqueObjectFinder UniqueObjectFinder {
	  add InputArray PhotonIsolation/photons photons
	  add InputArray ElectronIsolation/electrons electrons
	  add InputArray MuonIsolation/muons muons
	  add InputArray JetEnergyScale/jets jets
	}	

Before being processed by the UniqueObjectFinder module the "JetEnergyScale/jets" collection contains isolated particles as well (besides genuine QCD jets). The UniqueObjectFinder will set a higher priority the the isolated muons, so when an iso muon is found inside the jet collection, it will be removed from the jet collection. This said, it may very well be that some muons do not pass the isolation criteria, so they will still appear in the jet collection.

We do this by default for the lambda Delphes user, so that she doesn't have to worry about having the same object in different collection.
If you don't want this overlap removal to be done by Delphes, and you want to do it yourself offline instead, you should simply save in your output tree the JetEnergyScale/jets collection instead of UniqueObjectFinder/jets. That is:

module TreeWriter TreeWriter {
... 
#  add Branch UniqueObjectFinder/jets Jet Jet
  add Branch JetEnergyScale/jets Jet Jet
…
}

Cheers,
Michele

Note: See TracTickets for help on using tickets.