Fork me on GitHub

Opened 8 years ago

Last modified 3 years ago

#1084 new Bug

Bug affecting long-lived hadrons

Reported by: amonte Owned by:
Priority: minor Milestone:
Component: Delphes code Version: Delphes 3
Keywords: Cc:

Description

Hello Delphes Team,
we have found what seems to be a mistake in the way Delphes treats long-lived hadrons.

In the ParticlePropagator module, Delphes discards all stable particles (Delphes/stableParticles) if they are positioned outside the detector (according to the pythia event listing), no matter what the mother particles are. While this is ok for some neutral long-lived new physics particle that decays outside the detector, a long-lived SM hadron with a sizable boost can also have ctau larger than O(1) meters.

In this case Delphes discards the decay products of the long-lived hadron, which in the real world would have deposited its energy in the HCAL. We have verified that negelcting those particles produces spurious MET in new physics scenarios where there should be none (apart from momentum smearing and non-perfect efficiencies in the calorimeter), e.g. RPV (or Stealth SUSY) decays of neutralinos to quarks (gluons).

In ParticlePropagator, we have fixed this by manually relocating the long-lived decay products inside the detector. Because the problematic events involve large boosts (so large pTs), the decay products are usually collimated, so it seems to not matter wheter they are relocated at the origin or at the edge of the detector, but it is possible that other scenarios would be sensitive to this fix. We have verified that after the fix, the MET distribution agrees with the MET distribution from mismeasured multijet (QCD-only) background in ATLAS-CONF-2016-095, fig. 1-a (orange).

I am attaching an HepMC file with 1 event that reproduces the problem, together with the pythia event record (this is a pair-produced gluino decaying into a hidden sector, the final states being 6 jets and no MET). The stable particles originating from problematic long-lived hadrons are listed at the end of the log file. The hadrons are Sigma+/-, Lambda0 and K_S0, which if dropped result in a MET of about 400 GeV. Modifying the Delphes code to relocate their decay products, we otherwise get ~100 GeV of MET (if we turn off smearing and set calorimeter efficiencies to 1.0, the MET is on the order of a few GeV after relocating the displaced particles).

Do you agree with this being a problem? I think the proper way to treat this would be to only discard displaced particles when their mother(s) is truly invisible. It seems that the "Energy Fraction" specifications in the calorimeter module are made with that in mind, but I don't understand how they are used for non-stable particles (pi0, K0S, Lambda0): in that module, only stable particles (according to pythia/HepMC) are processed, but in my pythia event those are decayed beforehand, so Delphes never sees them.

Attachments (2)

gogostealth1.hep (495.1 KB ) - added by amonte 8 years ago.
HepMC file with long-lived hadrons
gogostealth1_pythia8.log (455.4 KB ) - added by amonte 8 years ago.
pythia 8 log file

Download all attachments as: .zip

Change History (4)

by amonte, 8 years ago

Attachment: gogostealth1.hep added

HepMC file with long-lived hadrons

by amonte, 8 years ago

Attachment: gogostealth1_pythia8.log added

pythia 8 log file

comment:1 by Pavel Demin, 8 years ago

I've just created a pull request with a simple modification of the ParticlePropagator module:

https://github.com/delphes/delphes/pull/42

This modification adds two parameters (RadiusMax and HalfLengthMax) to the ParticlePropagator module that can be used to keep decay products of the long-lived particles.

If the decay products appear between Radius and RadiusMax or between HalfLength and HalfLengthMax, then they are kept in the OutputArray collection. These particles aren't propagated. They aren't used for electron/muon/charged particle identification. They can only create energy deposits in the calorimeters.

comment:2 by Pavel Demin, 8 years ago

The modification that adds two parameters (RadiusMax and HalfLengthMax) to the ParticlePropagator module is now in the 3.4.1 release.

Version 0, edited 8 years ago by Pavel Demin (next)
Note: See TracTickets for help on using tickets.