Potential hidden cuts in the ATLAS run card ?

[Cyril Becot]

Dear Delphes authors,

(I put type "bug" but this may very well not be a bug at all ;))

I am trying to implement an analysis similar to the h->ZZ*->4l analysis of ATLAS, for the h(125) case in the VBF channel, using MG5+pythia8 passed through delphes for the detector simulation. I use the card delphes_card_ATLAS.tcl

As you know the off-shell Z boson decays to low pT lepton. The previous card had an embedded cut on pTl at 10 GeV, which I decreased to 5 GeV to cover the low pTl range used in the ATLAS analysis (as low as 6 GeV)

But still the events that I got as delphes output find the 4l only one time/10 which is very inefficient. Most of the time only 2 leptons are found. Given the efficiencies used in the cards I would have expected to find the 4l at a much higher rate

So I wanted to ask : is there another cut embedded in the runcard that I missed, or I have just overlooked something ?

Kind regards,
Cyril

[Michele Selvaggi]

Hi Cyril,

which version are you using?
Can you try downloading the latest version and running Delphes in standalone mode, as shown here:

https://cp3.irmp.ucl.ac.be/projects/delphes/wiki/WorkBook/QuickTour

A possible reason might be the isolation criteria that are too strong; you might want to try to relax them. Also, can you attach a small *hep event file (~1k events) so that we can have a look? Do you see the same effect in electrons and muons?

Michele

[Cyril Becot]

Dear Michele,

Thanks for your answer !
Just to make sure I have generated ZZ->4e, 4mu and 2e2mu separately and I got a similar efficiency of finding 4l in the three cases
I had relaxed the isolation (put set PTRatioMax 0.5 for both muons and electrons) and it did not increased the efficiency so much (I am at 15%, I would expect at least twice)
I was already using delphes 3.3.2 stand-alone
I will prepare you a small file tomorrow morning. But so far I have been using LHEF files (with DelphesLHEF), do you think it might also link to the problem ? And are this LHEF files ok with you or do you prefer hepmc ?

Thanks again
Kind regards

Cyril

[Michele Selvaggi]

Hi Cyril,

as a general you shouldn't use LHEF file as these don't contain showered/hadronized events;
Try to reproduce results with STDHEP or HepMC, and if the problem persist, please attach a small event file.

Michele

[Cyril Becot]

Hi Michele,

Actually these LHEF files are the output of pythia
To be more clear : I first run the event generation at fix-order in mg5 then pass it through pythia8 stand-alone for shower+hadronization but decided to get the pythia output as LHEF file, so I thought I would get hadronized and showered events (and I saw pions and kaons looking at the LHEF content so I was not really worried about that). However I'm not fluent in pythia so I'm likely mistaking. Can you confirm your remark in light of this ?

Thanks ! :)

Cyril

[Michele Selvaggi]

Hi Cyril,

I never use any output from pythia different than hepmc or stdhep so this looks strange, and what you are doing is definitely not standard from what i know. LHEF file are usually used for ME scatting events. Can you cross check by doing the default Pythia6 showering inside MG5 (you have to install pythia inside MG to do this via the mg command line "install pythia-pgs"?

Michele

[Cyril Becot]

Hi Michele,

So I re-did the showering inside MG5 + delphes standalone on the output .hep file
I still see the same problem. I suggested I attached the example .hep w/ 1k events (and I also attached the .tcl card I used, which is the ATLAS example without pile-up with relaxed pT/isolation cut). A bit more details below :

Doing Delphes->Draw("Electron_size+Muon_size","(Electron_size+Muon_size)>3") gives 234 events, and this only includes cuts at pT = 3 GeV, eta cuts at 2.5/2.7 + 50% for efficiency in the worst case ( 85%^{4 )}

A colleague did the count on a truth level sample and found an efficiency of 73% after PTl > 6, 10, 15, 20 GeV for 4 leptons and |eta_lept| < 2.5, which should be folded 50% for efficiency, and we are still too high wrt the 23% I got

Many thanks for following on this issue !
Kind regards
Cyril

[Cyril Becot]

modified TCL card

[Cyril Becot]

I have generated another sample with half the statistics, the first one did not fit on the website

Kind regards
Cyril

[Cyril Becot]

Showered events used as input to delphes

[Cyril Becot]

Hi Michele, Delphes experts,

Is there any news on that ?
I apologize for being so pushy, I'd like to know what's the status so I can search for another workaround if it is needed
for the timescale I would like to follow for this project

Kind regards
Cyril

[Alexandre Mertens]

Hello,

Just a quick test, what's happening if you comment the following line in the unique object finder?

  add InputArray PhotonIsolation/photons photons

Cheers,
Alexandre

[Alexandre Mertens]

Another possibility, and I think it is the issue you are looking for, is that by default, electrons and muons are included in the eflow collection, which is then used for the isolation computation.

Then if two leptons are close to each other, at least one of the two leptons won't be isolated.
So, the procedure would be to create an extra collection (i.e. isoobjects) as it is done in the Energy flow merger but removing the tracks as input. And then use this collection as IsolationInputArray for the electrons and muons isolation.