IAP GITLAB

Skip to content

Interface to the TAUOLA library for tau lepton decays.

Remy Prechelt requested to merge rprechelt_tauola_interface into master

This is a WIP merge-request containing a basic interface to the TAUOLA library for accurately simulating the decay of tau-/+ leptons. Since this is my first foray into CORSIKA8, I'm creating this MR at this preliminary stage to get early feedback. Where possible, I have followed the style and formatting of other CORSIKA processes for consistency (even though we have discussed modifying our coding style in the future in previous meetings).

This MR currently includes a working TAUOLA process and a very basic test suite (that decays tau- and tau+ particles and performs basic checks i.e. energy conservation, vertex checks, etc.) that directly uses a TAUOLA process instance.

Unfortunately, the TAUOLA API is very old-style C++. To perform the decay, you must provide a concrete implementation of an abstract TauolaParticle base class. The base class API is not const-correct (anywhere) and uses raw pointers liberally. It is also very lax about how many simultaneous raw pointers it may hold to the same underlying particle instance which makes any attempt at sneaking in smart pointers difficult. This CORSIKA<->TAUOLA interface is provided in the TauolaInterfaceParticle.hh file. The actual decay logic is implemented in TAUOLA.cc.

To avoid storing another large tar-ball in the repo, this MR uses CMake's ExternalProject interface to download and compile the TAUOLA source during the build process. If we would rather add the TAUOLA tar-ball to the ThirdParty directory, I'll update this MR.

The standard TAUOLA interface by default also returns short-lived daughters (W, Z, Eta, K0's) so you can pass them to another decay implementation (typically Pythia) if desired. However, it also has the ability to decay these particles directly but the built-in decay implementation may not be as high-precision (or updated as regularly) as Pythia's. This MR currently decays these short-lived daughters and adds the resulting stable particles to the stack (so Pythia is not required). If there is interest in adding these short-lived particles to the stack instead and decaying them separately in the Pythia interface (which currently does not support any of the above particles), let me know - we can also make this a configurable option if needed.

The main advantages of TAUOLA over Pythia for tau decays are:

  1. Tracking of the spin correlations (and the effect on the decay products) when tau pairs are created in a single interaction. This requires knowledge of the parent particle(s) and process(es) that created the tau pair. Unless I'm mistaken, this information is not available through the Stack interface (and hence not available to the DecayProcess) - at least in their current form. Therefore, these features currently remain off (in my experience, they are a second order effect)
  2. Handling the polarization vector of the tau during decay. Since CORSIKA does not track particle polarization (as far as I'm aware), this implementation assumes an unpolarized tau for each decay. I will push an additional commit tomorrow that allows the user to override the default polarization when instantiating the process (since there are astrophysical reasons to simulate a polarized tau).

My next objective is to produce some detailed CORSIKA TAUOLA <=> Pythia comparisons - I'll update the MR as things are completed. Hopefully, those comparisons will help guide the decision on whether Pythia or TAUOLA should be the default interface for tau decays.

Any and all feedback would be appreciated since I'm still grokking the CORSIKA8 internals.

NB: The CI/CD pipeline is currently failing when uploading artifacts to the coordinator. The tests pass in my local corsika-devel container.

Edited by Ralf Ulrich

Merge request reports