PaperlayerView exact revision on arXiv

Source-linked AI summary

Universal Interface of TAUOLA Technical and Physics Documentation

N. Davidson, G. Nanava, T. Przedzinski, E. Richter-Was, Z. Was

arXiv:1002.0543v1hep-ph

TL;DR

The paper addresses how to add τ decays to externally generated collision events while retaining the spin information connecting production and decay. It presents a configurable Monte Carlo interface that supplies production and spin data to TAUOLA and writes accepted decay products into event records. The interface adds transverse spin correlations and electroweak corrections, while its predictions remain limited by leading-log spin treatment and approximations for higher-order radiation.

  • Problem

    τ decays must be simulated separately from production while preserving spin connections and accommodating production-process information from external event generators.

  • Method

    A configurable TAUOLA interface reconstructs production information, builds spin-density weights, generates τ decays, and inserts accepted products into external event records.

  • Results

    The interface implements transverse spin correlations and genuine electroweak corrections, with effects reaching about 50% at several-TeV virtualities.

  • Takeaways & Limitations

    Spin, electroweak, and new-physics effects can be incorporated during τ-decay generation through interface configuration and data-table changes.

  • Takeaways & Limitations

    For initial-state parton-shower emissions, omitted terms may be of order αQCD/π, producing effects at the level of ten percent or so.

Abstract

from arXiv · show

Because of their narrow width, tau decays can be well separated from their production process. Only spin degrees of freedom connect these two parts of the physics process of interest for high energy collision experiments. In the following, we present a Monte Carlo algorithm which is based on that property. The interface supplements events generated by other programs, with tau decays. Effects of spin, genuine weak corrections or of new physics may be taken into account at the time when a tau decay is generated and written into an event record.

1 Introduction

The TAUOLA C++ Universal Interface separates τ-decay generation from production simulation while preserving spin connections and user configurability. It enables spin effects, electroweak corrections, and anomalous couplings to be incorporated when decays are generated.

  • Motivation and contribution: A modular interface avoids the reduced flexibility of black-box simulation chains when distinguishing experimental from theoretical effects.The paper links this flexibility to improved control of systematic errors.
  • Motivation and contribution: τ decays are implemented as a separate, end-user-configurable module within a simulation chain.The TAUOLA library itself remains a black box for High Energy experimental users.
  • Motivation and contribution: The interface prepares τ four-momenta and spin states for TAUOLA, inserts decay products into the event record, and calculates weights for unweighting.These weights can incorporate production and decay information.
  • Motivation and contribution: The C++ interface replaces the FORTRAN HEPEVT implementation with a HepMC-based interface and adds new functionality.The C++ version is designed for the C++ event-record environment.
  • Physics improvements: Transverse spin correlations for Z/γ∗ processes and genuine electroweak corrections are implemented relative to the FORTRAN interface.The interface also supports beyond-standard-model effects by replacing read-in data tables without modifying the code.

2 Requirements for TAUOLA Interface

The interface must reconstruct production and spin information from heterogeneous event records, apply density-matrix-based decay algorithms, and accommodate evolving conventions. Its operation is bounded by approximations in QCD kinematics and by generator-specific record structures.

  • General requirements: τ spin states and frames, or a density matrix for multiple τ leptons, are required to generate correlated decays.Decay products must be transformed between τ rest frames and the laboratory frame.
  • Approximations: Initial-parton kinematics for spin-density calculations are currently treated only in the leading collinear approximation.Higher-order QCD corrections are identified as an additional source of approximation.
  • General requirements: The algorithm locates τ leptons, determines their production process, reconstructs incoming-field orientation, and uses this information to calculate spin correlations.For W or charged-Higgs processes, ντ must also be localized.
  • Event-record requirements: The C++ interface can attach to Monte Carlo programs whose τ output is available through HepMC, including applications that replace measured muons with generated τ pairs.The design anticipates flexible adaptation to different HepMC usage patterns.
  • Event-record requirements: HepMC conventions vary across generators and processes in status codes, documentary information, vertex pointers, and energy-momentum conservation.The interface therefore declares conventions it can interpret, including bidirectional pointers and vertex-level conservation assumptions.
  • Event-record requirements: Missing intermediate bosons are handled by approximating the dominant single diagram, while statistical choices and higher-order hard-process treatments are unavailable.This is an explicit scope boundary of the event-record interpretation.
  • Event-record requirements: Host-specific patches may be needed for new event-record conventions, making debugging time-consuming and repetitive.The paper notes that such options may not form an algebraically closed structure.

3 Design

The design separates TAUOLA FORTRAN routines, an abstract C++ interface, and event-record-specific implementations. Its algorithm traverses HepMC records, constructs spin information, generates and accepts τ decays, then writes transformed daughters back into the event.

  • Interface structure: The source is divided into three modules separating FORTRAN code, abstract C++ interfaces, and concrete event-record implementations.This modularity isolates library-specific and record-specific responsibilities.
  • Implementation modules: The TAUOLA FORTRAN layer wraps initialization and decay routines, while filhep inserts generated particles into the HepMC event record.The FORTRAN distribution is retained intact for future updates.
  • Interface structure: The abstract layer represents events, particles, and particle pairs independently of the event-record format.TauolaParticlePair handles polarization and decay algorithms for related particles.
  • Interface structure: The event-record layer reads, traverses, and writes specific structures; the HepMC implementation uses TauolaHepMCEvent and TauolaHepMCParticle.Only the abstract event and particle classes must be implemented for a new record interface.
  • Package organization: The package includes utilities, examples, electroweak-correction code, headers, libraries, documentation, and the retained TAUOLA FORTRAN distribution.Examples cover standalone HepMC events, Pythia-linked single-τ decay, and MC-TESTER analysis.
  • Algorithm outline: The algorithm creates a TauolaHepMCEvent, checks units, locates stable τ leptons, reconstructs production trees, and pairs siblings.For each pair it builds a density matrix, executes DEKAY, calculates a spin weight, and repeats rejected decays until acceptance.
  • Algorithm outline: Accepted decay products are transformed from the τ-pair reference frame to the hard-process frame and inserted into the event record.The τ status is changed and new HepMC daughter objects and tree structures are created.

4 Calculation of Spin Correlations

The interface simulates tau spin correlations by weighting generated decays with production density matrices and decay polarimetric vectors. It accommodates complete spin effects, weak corrections, and new-physics modifications, while its approximations limit precision in radiation-rich events.

  • Spin-correlation algorithm: Tau-decay pairs are accepted or rejected using a weight built from decay polarimetric vectors and the production density matrix.For rejected pairs, decays can be regenerated or rotated and reweighted without reprocessing the production event.
  • Spin-correlation algorithm: The density matrix depends on the production mechanism and kinematics, while each polarimetric vector depends on the corresponding tau decay.For multiple taus, the complete correlation matrix is required; the same algorithm also applies to tau-neutrino production.
  • Event reconstruction: The interface reconstructs hard-process variables and incoming-beam flavour to calculate polarization or electroweak-correction weights.For tau pairs with radiation or unavailable intermediate states, effective Born-level variables and incoming flavours must be reconstructed.
  • Complete spin effects: The initially presented density matrix contains only longitudinal spin correlations, but the interface can pass complete spin effects without further simulation changes.The matrix representation is prepared to accept complete spin information, including genuine weak effects and new-physics contributions.
  • Complete spin effects: Helicity states are assigned after tau decays are generated and accepted, including processes mediated by intermediate Z/γ∗ or Higgs bosons.The program provides these helicities even when exact spin effects were used during generation.
  • Accuracy and limitations: The approximation reaches αQED/π ≃ 0.1 - 0.2 % precision for observables without explicitly required high-pT photons, while omitted initial-state-shower terms remain at roughly ten percent.Further improvement requires explicit higher-order matrix elements.
  • Extensions: Externally calculated density matrices can replace the documented matrices to study new-physics spin correlations or modify spin effects component by component.This supports investigations such as the influence of spin correlations on signal/background separation.

5 Electroweak Corrections and Refined Spin Effects

The interface supports refined spin-density calculations, including externally supplied electroweak-corrected matrices, while reconciling differing frame conventions between TAUOLA and SANC. Electroweak corrections are small near the Z peak but become substantial at multi-TeV virtualities, motivating their inclusion in new-physics studies.

  • 5.1 External Calculation of the Spin Density Matrix Rij: The interface calculates simple spin density matrices for most relevant hard processes and can also accept externally calculated Rij matrices.The external-matrix option is useful when standard density matrices are insufficient, notably for quark-annihilation production of τ+τ−.
  • 5.1 External Calculation of the Spin Density Matrix Rij: SANC supplies Rij for q̄q → τ+τ− as functions of incoming flavour, Mandelstam s, and scattering angle θ, with weights that switch genuine weak corrections on or off.Pretabulated Rij values are stored over (s, cos θ) points and interpolated during interface execution.
  • 5.1 External Calculation of the Spin Density Matrix Rij: User-modifiable SANC results can be loaded into the interface without changing its code, supporting extensions such as heavy Z′ calculations.The interface performs rotations and convention adjustments when preparing Rij tables for the differing SANC and TAUOLA frame orientations.
  • 5.2 Conventions of Frames: KORALB, SANC and TAUOLA Interface: The interface and SANC use different reference-frame conventions for beam directions and spin axes, requiring explicit convention adjustments before Rij tables are used.In the interface frame, the z axis follows the anti-particle beam, whereas SANC uses the particle-beam direction.
  • 5.3 Numerical Significance of Electroweak Corrections: 1% corrections occur up to 100 GeV above the Z-boson mass, whereas effects can reach 50% at virtualities of several TeV.The corrections are small up to about 500 GeV for the reported τ-polarization results and become sizable at larger scales.
  • 5.3 Numerical Significance of Electroweak Corrections: Electroweak corrections should be considered in studies of new-physics phenomena such as Z′ → τ+τ− decays.The paper identifies high-energy virtualities as the regime where these corrections become practically significant.

6 Tests of Spin Correlations and Numerical Results

The interface’s physics tests examine longitudinal and transverse spin effects in Z, Higgs, W, and charged-Higgs processes, comparing distributions with spin effects included or neglected. The results reproduce expected polarization and pion-spectrum behavior, while identifying experimentally difficult transverse observables.

  • Testing strategy: The tests use MC-TESTER to compare invariant-mass distributions and validate the C++ interface against the established FORTRAN interface.The FORTRAN implementation had been validated against analytical and numerical calculations for tau-pair production.
  • Longitudinal spin effects: Z-decay tests reproduce published effects of Z polarization in the π+π− invariant-mass and pion-energy distributions.The tau decay mode is restricted to τ ± →π±ντ.
  • Longitudinal spin effects: Higgs longitudinal-spin tests show the expected flat pion-energy distribution in the Higgs rest frame.The tested observables include Mπ+π− and the pion-energy distribution.
  • Transverse spin effects: Transverse-spin effects are large for Higgs decays to π±ντ, but the corresponding acollinearity and acoplanarity observables require unobservable neutrino momenta and difficult reaction-frame reconstruction.These limitations make sufficient experimental precision difficult or impossible to achieve for those observables.
  • Transverse spin effects: The ρ-pair acoplanarity test uses directly measurable pion momenta and does not require Higgs-rest-frame reconstruction.Events are categorized by the signs of charged–neutral pion energy differences.
  • W and charged-Higgs tests: The pion spectrum is softer for W decays and harder for charged-Higgs decays, with the two spectra reversed between the processes.This expected behavior is reproduced in the W and H+ rest-frame distributions.

7 Outlook

The outlook extends TAUOLA’s interface toward experimentally reconstructed spin states and broader event-record support. It also notes that the current implementation remains HepMC-based, framework-like, and partly organized around a growing hard-process analysis component.

  • Future extensions: Future work will generate spin states from quantities measurable in real data and address systematic errors from reconstructed states, including QCD corrections.This is identified as a planned extension of the TAUOLA Universal Interface.
  • Architecture: The interface currently targets HepMC, but its design permits adaptation to other event structures through an appropriate event-record interface.The current HepMC implementation is described as the active design target.
  • Architecture: TAUOLA Universal Interface and TAUOLA remain framework-like code intended for user modification for particular purposes.The tau-decay library is treated as a black box from the C++ interface perspective.
  • Architecture: The hard-process analysis and spin-state generation code has become a significant project component and is planned for migration into a separate class.The document states that this component already exceeds peripheral interface methods in size.
  • Decay-model development: Future improvements include replacing the FORTRAN decay directory with versions incorporating better hadronic form factors and refined decay models.The anticipated inputs are tau data from the Belle and BaBar collaborations.
  • Interface routines: The documented interface exposes initialization, decay, event-record, polarization, and four-vector routines for configuring and generating tau decays.The listed routines include DEKAY, DEXAY, initialization functions, event-record insertion, and boost or mass utilities.

B.2 Elementary Tests

The elementary tests verify installation, tau decay execution, event-record consistency, and energy–momentum conservation before physics-oriented validation. They also provide reproducible MC-TESTER comparisons and benchmark files for testing installations and code changes.

  • Elementary checks: The basic installation test checks that all tau leptons decay, energy–momentum is conserved, and no double decays occur in the event tree.These checks complete the first installation-testing step once confirmed.
  • Elementary checks: Tau-mass differences between the production program and TAUOLA can prevent decay-product momenta from exactly matching the parent tau momentum.TAUOLA maintains its own parameter database, including the tau mass.
  • Elementary checks: Installation tests should be repeated for each new hard process and installation because event-record misinterpretation can omit spin correlations or leave taus undecayed.The tests ensure that information is passed from the event record to the interface as expected.
  • Advanced tests: Advanced tests validate the installation while demonstrating how spin affects selected distributions.Examples cover intermediate states including Z, W, H, and H±.
  • Testing workflow: The testing workflow compiles the interface and examples, configures environment variables, selects a test directory, and runs make.Generated ROOT and PDF outputs support inspection of the comparisons.
  • Validation resources: Benchmark MC-TESTER files packaged with the distribution enable comparison plots for validating new installations and interface versions.The examples produce comparison booklets against benchmark files.
  • Validation resources: The tau-decay demo compares a user run with a pre-generated sample of 10 million events while activating all tau decay modes.MC-TESTER analyzes the tau decays themselves in this test.

B.5 Known Issues

The interface documentation covers configuration, compatibility, and testing issues, while exposing controls for spin correlations, decay modes, and particle assignments.

  • Compatibility issues: Unit mismatches between PYTHIA and HepMC cause TAUOLA to interpret and produce four-vectors in incorrect units.Warnings about nonconserved four-momentum identify this configuration problem; forcing HepMC to use MeV before filling converts the event to GeV automatically.
  • Compatibility issues: HepMC 2.03 lacks unit-conversion methods, so inputs and outputs are expected in GeV and mm.A compatibility script is invoked automatically for the older version, while Tauola::setUnits(...) is associated with unit handling.
  • Compatibility issues: Athena integration requires interface modifications for older HepMC compatibility and to avoid naming clashes when both TAUOLA interfaces are loaded.The Athena-specific changes are applied through platform/to-Athena.sh followed by recompilation.
  • Configuration: Spin correlations are enabled by default but can be globally, selectively, or density-matrix controlled for numerical validation studies.The interface supports switching all correlations or selected parent processes, and replacing the density matrix without recompiling.
  • Configuration: Users can select same- and opposite-charge tau decay modes and modify channel branching ratios through Tauola configuration methods.The documented controls include particle-specific mode selection and per-channel branching-ratio changes, with normalization performed automatically.

C.4 Radiative Corrections

TAUOLA exposes controls for radiative corrections in leptonic tau decays and optional decay of short-lived scalar daughters, with precision and channel coverage limits.

  • Radiative corrections: Radiative corrections for leptonic tau decays are enabled by default and can be switched off with Tauola::setRadiation.The radiation cutoff can also be configured; the default explicitly generates photons up to 0.01 of half the decaying-particle mass in its rest frame.
  • Radiative corrections: TAUOLA’s radiative-correction algorithm is limited to leptonic decays, uses the complete first-order matrix element, and has no exponentiation.PHOTOS may be used when multiple photons or corrections for other decay channels are needed.
  • Scalar daughters: The interface can decay short-lived scalar particles produced in tau decays instead of delegating post-processing to the host generator.The documentation cautions that high precision is not assured, making the option more suitable when such decays are rare.
  • Scalar daughters: Tauola::setEtaK0sPi independently switches eta, K0s, and pi0 decays on or off using three binary parameters.A value of 1 enables a decay and 0 disables it.

C.6 Scalar-Pseudoscalar Higgs

The interface supports spin-correlation studies for scalar, pseudoscalar, and mixed scalar-pseudoscalar tau production, while exposing event-level helicity and electroweak-weight accessors.

  • Scalar-pseudoscalar treatment: Spin density matrices are calculated automatically for scalar Higgs PDG id 25 and pseudoscalar Higgs PDG id 36.Other mixed or non-Higgs scalar cases require explicit configuration.
  • Scalar-pseudoscalar treatment: Mixed scalar-pseudoscalar treatment is configured through the Higgs PDG code and a scalar-pseudoscalar mixing angle.The coupling is parameterized as τ̄(cos(φ) + isin(φ)γ5)τ, with default mixed-state PDG id 35.
  • Radiative-correction scope: The documentation notes that omitted first-order matrix-element components can matter more numerically than multiple-photon effects in standard tests.This conclusion may not hold for other applications.
  • Event information: Approximate tau-plus and tau-minus helicities can be retrieved after processing, but they are not used by the interface.Their actual signs may depend on the process and boosting routine.
  • Event information: After event processing, accessors return electroweak weights for corrected and Born-level cross sections.Tauola::getEWwt() provides the corrected weight, while Tauola::getEWwt0() provides the Born-level quantity.

C.8 Use of TAUOLA decayOne method

The decayOne method generates an individual tau decay independently of event-record parent information and accepts polarization inputs, with customizable boosting for lab-frame products.

  • Purpose and interface: Tauola::decayOne decays a single tau without requiring information about its parents.This is intended for applications testing different new-physics model flavors or otherwise lacking universal parent-based spin-state information.
  • Polarization: The final three decayOne arguments specify the components of the tau polarization vector.The first argument, a tau pointer, is mandatory.
  • Purpose and interface: The undecay flag controls whether an already decayed tau remains unchanged or is replaced by a newly generated decay.Its default is false; setting it true first removes the existing decay.
  • Boosting: A user-supplied boost routine can replace the default transformation from the tau rest frame to the laboratory frame.This may support future exact spin-correlation algorithms for mult tau final states.
  • Boosting: With the default example, polarization (0,0,1) represents a helicity state, but with the custom boost it represents a lab-frame z-oriented spin vector.The interpretation therefore depends on the selected boost routine.

C.9 Logging and Debugging

TAUOLA Interface provides logging, message filtering, memory-leak tracking, and plotting utilities for testing and debugging. Debugging features can impose substantial runtime or compilation constraints in user programs.

  • Logging: The logging tool summarizes messages, reports summaries at program exit, and toggles info, warning, error, debug, or all-message output.Debug messages can be restricted to a code range; an inverted range suppresses them.
  • Memory leak tracking: Debug mode significantly increases runtime and is recommended only for debugging purposes.The option is enabled by modifying make.inc and recompiling the interface.
  • Memory leak tracking: Memory-leak tracking lists unfreed pointers and their consumed memory after execution, producing an empty table when no leaks remain.The interface must be recompiled after enabling the option.
  • User-program integration: The debugging macro can cause compilation errors with software using its own memory-management system, such as ROOT.Log.h should be the last header included in the main program.
  • Plotting: The plotting tool generates data files for monitoring τ polarization and SANC interpolation, primarily for testing, debugging, and installation checks.External scripts, including the supplied ROOT script, can turn generated files into plots.

C.11 Other User Configuration Methods

TAUOLA offers auxiliary configuration methods and SANC integration for units, lifetimes, random generators, electroweak settings, and tabulated corrections. During initialization, compatible SANC tables are loaded; invalid or missing files cause the interface to fall back to available data or default density matrices.

  • Auxiliary methods: Auxiliary methods configure output units, τ lifetime, QED-related initialization constants, and replacement random-number generators.Custom generators must return a double between 0 and 1.
  • SANC initialization: SANC initialization sets particle and electroweak parameters, including masses, charges, weak isospin, infrared regularization, and radiation-separation settings.Flags control NLO QED, NLO electroweak, Born, and calculation-scheme options.
  • SANC tables: The SANC interface generates pretabulated files for down- and up-type quarks, with table generation invoked using make tables.The generated files contain dimensions, ranges, metadata, initialization parameters, and Rij data blocks.
  • SANC table loading: TAUOLA loads the three SANC files during initialization when they are found in the main program directory.The interface checks data-block completion and proceeds file by file.
  • SANC table loading: If a SANC file is missing, malformed, or dimensionally incompatible, its data are excluded; incompatible input causes use of the default density matrix.Correctly loaded files may still be used when another file is incorrect or missing.
  • SANC table generation: The SANC folder supplies routines and Makefile targets for recompiling the library, cleaning builds, and regenerating tables.Further options, including electroweak constants and particle masses, can be modified in the interface code.
Loading 1002.0543v1…