Fork me on GitHub

Opened 10 years ago

Closed 10 years ago

#319 closed Bug (fixed)

"Ghost muons" from previous events?

Reported by: Andrea Giammanco Owned by:
Priority: major Milestone:
Component: Delphes code Version: Delphes 3
Keywords: replicas Cc:

Description

Dear developers,
I am finding something very puzzling in my Delphes output. You can find below [1] the instructions to reproduce exactly what I do, but I first start by describing what I see: in some events there are some reconstructed muons that do not match any MC-truth muon in the same event, but do match muons in some previous event!

For example:

* event n.32

Muon-MC-truth pt: 100.102, eta: 0.0903997, phi: 2.94831, status: 23
Muon-MC-truth pt: 100.102, eta: 0.0903997, phi: 2.94831, status: 1
Muon-MC-truth pt: 4.95513, eta: -0.677423, phi: -2.02726, status: 1
Muon-MC-truth pt: 28.9477, eta: 0.732578, phi: -0.0825566, status: 1
Muon-MC-truth pt: 5.81811, eta: -0.394295, phi: -0.450551, status: 1

Hard Muon pt: 102.098, eta: 0.0903997, muon: 0.0322827

Soft Muon pt: 102.098, eta: 0.0903997, phi: 2.94831
Soft Muon pt: 29.5569, eta: 0.732578, phi: -0.0825566
Soft Muon pt: 5.90183, eta: -0.394295, phi: -0.450551
Soft Muon pt: 5.06428, eta: -0.677423, phi: -2.02726

(here every Hard and Soft Muon matches with some MC-truth muon, so it is ok)

* event n.35

Muon-MC-truth pt: 22.2056, eta: -0.107981, phi: 1.90628, status: 1
Muon-MC-truth pt: 0.46618, eta: 0.261316, phi: -0.0885699, status: 1

Muon-in-jet pt: 5.90183, eta: -0.394295, phi: -0.450551
Muon-in-jet pt: 5.06428, eta: -0.677423, phi: -2.02726

Soft Muon pt: 22.2756, eta: -0.107981, phi: 1.90628

As you can see, here in evt n.35 the two muon-in-jet don't match any MC-truth muon, but are exact replicas of the last two Soft Muons of evt n.32!

Here I must explain that Soft Muons are a special collection that I added to Delphes (see [1b]) while Muon-in-Jet is defined by looping over the jet constituents of the jets that pass my selection, and checking whether they are flagged as muons:

for(Int_t j = 0; j < jet->Constituents.GetEntriesFast(); ++j) {

object = jet->Constituents.At(j);
Check if the constituent is accessible
if(object == 0) continue;
if(object->IsA() == Muon::Class()) {

muonInJet = (Muon*) object;
cout << " Muon-in-jet pt: " << muonInJet->PT << ", eta: " << muonInJet->Eta << ", phi: " << muonInJet->Phi << endl;

}

}

Any suggestion is appreciated. I am suspecting that somehow the jet clusterizer is taking as input also "ghosts" of particles from previous events, for reasons beyond my understanding.

[1]

a) Input file can be taken from
http://users.ph.tum.de/estamou/secure/ttbar_samples/
The example that I gave is from ttbar_sample_unpolarised_twoLambda.hepmc.dat which is inside ttbar_unpolarised.zip

b) I slightly modified Delphes in order to add a collection of muons called softmuons, defined by just inverting the isolation cut:
https://twiki.cern.ch/twiki/bin/view/Main/LambdaBPolDelphesAnalysis#Files_I_modified
I don't expect that this can have anything to do with my issue, but I am mentioning it for completeness.

c) My analysis macro:
https://twiki.cern.ch/twiki/pub/Main/LambdaBPolDelphesAnalysis/analyzeLambdab.C

Attachments (1)

analyzeLambdab.C (33.7 KB ) - added by Michele Selvaggi 10 years ago.

Download all attachments as: .zip

Change History (4)

comment:1 by Michele Selvaggi, 10 years ago

Ciao Andrea,

this looks very odd indeed..
i am trying to have a look at the detector card you are using on this link:
https://twiki.cern.ch/twiki/bin/view/Main/LambdaBPolDelphesAnalysis#Files_I_modified

but it seems I cannot access for some reason.

Probably best would be that you produce a tar ball containing your modified version of Delphes + a small event sample so I can to reproduce the bug. Maybe the easiest is that you put it on ingrid or lxplus.

Thanks,
Michele

by Michele Selvaggi, 10 years ago

Attachment: analyzeLambdab.C added

comment:2 by Michele Selvaggi, 10 years ago

Jet collections used to be formed from track, tower and muon objects. Recently we have simplified the workflow and simply merged muons together with tracks, before clustering the jet.

What is happening is you are trying to access muons which are not jet constituents (actually they are but they are stored as tracks, not as muons) and for some reasons these muons are set equal to some real muons found in previous events.

You probably have been inspired by Example3.C, which still tries to access muons in jets. Indeed this can be misleading and needs to be changed. Thanks for spotting this.

I have attached here a modified version of your macro that should do what you want.

Michele

comment:3 by Pavel Demin, 10 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.