ReDecay, a method to re-use the underlying events

This page is intended to collect practical information on using ReDecay. This includes both the a quick overview on how it is implemented, how it can be activated and cases where it must be used with caution. Additionally, the effect of re-using parts of an event and hence sacrificing the statistical independence of different events is explained and potential solutions is outlined. However, these should just be used as guidelines while the actual treatment of these effects is highly dependent on the actual analysis and must hence be discussed among the respective analysts with care.

Implementation and usage

Implementation details

In principle, the following procedure is implemented in Gauss:

  1. A full MC event including the signal decay is generated. This ensures that the signal, whose kinematics will stay fixed with new decays being generated can decay such that is passes the generator level cuts. This eliminates the risk of ending in an infinite loop.
  2. Before the generated particles are passed through the detector simulation, the signal and its decay products are removed from the event and the origin-vertex position and momentum of the signal particle are stored.
  3. The remaining event is simulated as usual and the entire output, the information on the true particle and the energy depositions in the detector, is kept.
  4. A signal decay is generated and simulated using the stored origin vertex position and momentum.
  5. The persisted underlying event and the signal decay are merged and written out to disk as a full event.
  6. Repeat N times from step 4.

In practice, the following modifications to the usual Gauss event loop have been made:

  • The usual Generation + Simulation loop is kept identical using the same configuration with the exception of two modifications:
    1. One algorithm that ensures the sequence is only executed once every N events.
    2. One algorithm to remove the particles to be redecayed and their decay products from the HepMC event produced by the generator.
  • A second Generation + Simulation sequence is added which is executed for every event and does the generation and simulation of the signal particles:
    1. In this sequence, calls to Pythia are replaced by a fake production tool which creates an event consisting only of the particles to be redecayed. This event is then processed identically to the nominal sequence (i.e. decayed using EvtGen to your final state etc). This approach allows to flexibly treat even multiple particles that are redecayed. The most common use-case here is the redecay of all particles heavier than your signal particle which usually includes both heavy flavour branches of your event.
    2. The decay products are then simulated by Geant4 as usual.
    3. A second algorithm then merges the two sets of MCParticle/MCVertex/MCHits/... structures and correctly connects the particles and vertices.
    4. These merged events are then written out as usual. Every combinations of the underlying with on signal decay counts as an event in the Gaudi sense!
  • Furthermore, the event and runnumber of the original event, i.e. the event that starts the sequence of events with the same underlying event, are encoded in the unused event time in the MCHeader. Additionally, from Sim09d onward, a new flag was added to MCParticle which indicates whether the particle is part of the underlying event or was part of the ReDecay branch.

After Gauss, the events are digitized as usual running Boole and hence underlying event and signal deposits correctly overlap. In fact, the aforementioned additional pieces of information encoded in the event data, it is impossible to tell, event-by-event, whether a specific event was produced with or without ReDecay after the Gauss step.

Usage

ReDecay can be turned on by added and controlled by the following options:

from Configurables import Gauss
Gauss().Redecay['active'] = True
Gauss().Redecay['N'] = 100 # 100 is the default.
Gauss().Redecay['rd_mode'] = 0 # Redecay signal
Gauss().Redecay['rd_mode'] = 1 # Redecay everything heavier than signal (default)

The configuration for the generation + simulation sequence used for the signal decay is automatically parsed and adapted from the configuration applied to the main sequence which is used for nominal productions. MCTupleToolRedecay can be used to add branches to an ntuple giving the event and runnumber of the original event.

TODO No tool exists to extract the additional flag from MCParticles.

Considerations and potential problems

There are several potential pitfalls one should be aware of when trying to apply ReDecay, both related to the automatic parsing and configuration of the signal sequencer:

  • As SampleGenerationTools, only SignalPlain and SignalRepeatedHadronization have yet been tested and necessary additions to the configuration have been made. While SignalPlain can be used as is in the signal sequencer, SignalRepeatedHadronization cannot be applied directly as the fake events containing only the particles to be redecayed cannot be hadronized again.
  • Generator cuts that access information outside of the signal decay must be treated with utmost care as it is not a priori obvious whether this information will be accessible in the fake events seen by the cut tool in the signal sequencer. However, if your cut tool only looks at the signal and its decay products, everything is fine!

Statistically non-independent events

Stop This is still a placeholder section. More information can be found in the documents linked below!

Explanation of the origin

The main problem when re-using the underlying event multiple times is that the resulting events are not statistically independent anymore, something that is usually taken for granted when doing analyses without ever thinking about it. This correlation is obvious for the actual parts of the underlying events (e.g. the question 'How many pions were produced in the primary collision which are not part of the signal decay?' will always yield the same answer). More problematic here however is the fact that the kinematics of the signal decay are also staying the same and hence when filling a histogram with, e.g. the signal pT, and assuming independent events and assigning a sqrt(N) uncertainty will lead to very large fluctuations that are not compatible within the assigned uncertainties. This is caused by a 100% correlation of said quantity between events stemming from the same original event. The behavior becomes less obvious once other quantities are studied. For example, the correlation will be substantially smaller when looking at decay product kinematics as the decay is regenerated every time and, while the boost of the signal particle is applied, retain a much larger amount of freedom. In the most extreme case such as Dalitz variables that do not depend on the rest-frame and hence the signal particle these correlations are vanish.

Various examples and illustrations for the effect can be found in the documents below.

Treatment

In general, this will highly depend on the analysis itself and needs to be judged by the analysts. While certain analysis such as amplitude analysis are likely much less affected as they rely on Dalitz variables, most analyses will need to take into account these correlations and replace naive sqrt(N) uncertainties by correctly estimated ones where the MC samples are concerned.

One possibility is the use of resampling techniques that generate pseudo-samples. Examples are discussed in detail in the documents below.

TODO Add further details on potential resampling techniques with some code snippets how one could easily implement them.

Additional documentation

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r4 - 2018-10-02 - DominikMueller
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback