ddsim: Vertices of tau and its decay product not matching the information in the input HEPMC file

[zwu0922]

Check duplicate issues.

• Checked for duplicates

Goal

Hi, I attempted to run ddsim for the ee->Z(vv)H(tautau) process using a HEPMC3 file as input. However, when I print out the MCParticles branch of the output of ddsim, I find that:
(1) The vertex information of final state particle does not match what is provided in the input HEPMC3 file. For instance, in the HEPMC3 input, the vertex of pi0 is (-0.931604, -1.01487, 1.19801), while ddsim produces (-0.931873, -1.01518, 1.19837)
(2) Vertices of intermediate tau leptons do not correspond to what is provided in the HEPMC3 file either (5.95634e-13, 1.22708e-13, 5.04033e-12), and are set to the origin (0,0,0).

I tried the solution mentioned in a previous issue. But the vertices of tau and decay products do not seem to be affected in the output root file, even if I manually change all particle status in the HEPMC3 from 22 or 23 to 2.

Operating System and Version

Red Hat Enterprise Linux 9.5 (Plow)

compiler

gcc (Spack GCC) 14.2.0

ROOT Version

6.32.04

DD4hep Version

94df2c6

Reproducer

Run ddsim with the following input file testZH.hepmc3 (extract in advance, github does not support uploading .hepmc3 file) testZH.zip

source /cvmfs/sw-nightlies.hsf.org/key4hep/setup.sh -r 2025-02-10
wget https://github.com/user-attachments/files/18737172/testZH.zip
unzip testZH.zip
ddsim --hepmc3.useHepMC3 True --numberOfEvents 1 --inputFiles testZH.hepmc3 --outputFile ALLEGRO_testHEPMC.root --random.enableEventSeed --random.seed 42 --compactFile $K4GEO/FCCee/ALLEGRO/compact/ALLEGRO_o1_v03/ALLEGRO_o1_v03.xml

Step 3: Examine the output root file
root ALLEGRO_testHEPMC.root
While in root: events->Show(0)
It can be easily noticed that printed values of MCParticles.vertex.x/y/z for tau and its decay product do not match the vertex information in the input HEPMC3 file.

Additional context

k4geo version: bfad786

[andresailer]

Hi @zwu0922

The tau lepton is charged, so it will be deflected by the magnetic field, which means it will have a different decay vertex than from the MC Input. No matter what we do, this will be the case.

With respect to the intermediate tau leptons:

The issue is that the particle with PDG 25 is not simulated, so that all its child particles are placed at its origin, which puts the intermediate taus at 0,0,0, they don't have any lifetime, so the next generation starts there as well.

The difference is femtometer, isn't it? So really nothing that would cause any observable difference in the output, would it?

[zwu0922]

Hi Andre, thanks for looking into this issue

Hi @zwu0922

The tau lepton is charged, so it will be deflected by the magnetic field, which means it will have a different decay vertex than from the MC Input. No matter what we do, this will be the case.

I switched off the magnetic field by setting both lines 57 and 58 to 0.0*tesla. The pi0 vertex now becomes (-0.931881, -1.01517, 1.19837), which is slightly different from the case where the magnetic field is switched on, but still doesn't correspond to the vertex in the input HEPMC file.
The tau seems to travel a bit longer in ddsim?

With respect to the intermediate tau leptons:

The issue is that the particle with PDG 25 is not simulated, so that all its child particles are placed at its origin, which puts the intermediate taus at 0,0,0, they don't have any lifetime, so the next generation starts there as well.

The difference is femtometer, isn't it? So really nothing that would cause any observable difference in the output, would it?

I see. Yes, I agree that the life time of the Higgs boson (PDGID==25) should not make much difference.

[andresailer]

DDSim: -0.931881, -1.01517, 1.19837
HepMC: -0.931604, -1.01487, 1.19801
Delta: -0.000277, -0.00030, 0.00036

We are feeding the correct proper time into Geant4

DD4hep/DDG4/src/Geant4InputHandling.cpp

Line 449 in 8f88ea1

p4->SetProperTime(proper_time);

I haven't found what Geant4 is doing exactly with this information. E.g., when it decides to decay a particle, how fine the stepping is for example.

[danieljeans]

in addition, I think that the crossing angle boost applied in ddsim also affects the taus' decay points ?

[andresailer]

in addition, I think that the crossing angle boost applied in ddsim also affects the taus' decay points ?

Yes, but that is not enabled in this case. Vertex Smearing would also change the position.

[andresailer]

Call Stack

#1  0x00007fffbf255a5f in G4Decay::PostStepDoIt (this=<optimized out>, aTrack=..., aStep=...)
    at /build/jenkins/workspace/lcg_release_pipeline/build/projects/Geant4-11.3.0/src/Geant4/11.3.0/source/processes/decay/src/G4Decay.cc:517
#2  0x00007fffc2d6174a in G4SteppingManager::InvokePSDIP (this=this@entry=0x1e324610, np=np@entry=2)
    at /build/jenkins/workspace/lcg_release_pipeline/build/projects/Geant4-11.3.0/src/Geant4/11.3.0/source/tracking/src/G4SteppingManager.cc:812
#3  0x00007fffc2d617eb in G4SteppingManager::InvokePostStepDoItProcs (this=this@entry=0x1e324610)
    at /build/jenkins/workspace/lcg_release_pipeline/build/projects/Geant4-11.3.0/src/Geant4/11.3.0/source/tracking/src/G4SteppingManager.cc:784
#4  0x00007fffc2d61b69 in G4SteppingManager::Stepping (this=0x1e324610)
    at /build/jenkins/workspace/lcg_release_pipeline/build/projects/Geant4-11.3.0/src/Geant4/11.3.0/source/tracking/src/G4SteppingManager.cc:219
#5  0x00007fffc2d6c555 in G4TrackingManager::ProcessOneTrack (this=0x1e56dc30, apValueG4Track=apValueG4Track@entry=0xaf614b60)
    at /build/jenkins/workspace/lcg_release_pipeline/build/projects/Geant4-11.3.0/src/Geant4/11.3.0/source/tracking/src/G4TrackingManager.cc:127
#6  0x00007fffc85befe5 in G4EventManager::DoProcessing (this=0x1e373320, anEvent=<optimized out>, trackVector=trackVector@entry=0x0, IDhasAlreadySet=IDhasAlreadySet@entry=false)
    at /build/jenkins/workspace/lcg_release_pipeline/build/projects/Geant4-11.3.0/src/Geant4/11.3.0/source/event/src/G4EventManager.cc:216
#7  0x00007fffc85bf40c in G4EventManager::ProcessOneEvent (this=<optimized out>, anEvent=<optimized out>)
    at /build/jenkins/workspace/lcg_release_pipeline/build/projects/Geant4-11.3.0/src/Geant4/11.3.0/source/event/src/G4EventManager.cc:458
#8  0x00007fffc3399219 in G4RunManager::ProcessOneEvent (this=0x1e2eceb0, i_event=0)
    at /build/jenkins/workspace/lcg_release_pipeline/build/projects/Geant4-11.3.0/src/Geant4/11.3.0/source/run/src/G4RunManager.cc:413
#9  0x00007fffc3398544 in G4RunManager::DoEventLoop (this=0x1e2eceb0, n_event=1, macroFile=<optimized out>, n_select=<optimized out>)
    at /build/jenkins/workspace/lcg_release_pipeline/build/projects/Geant4-11.3.0/src/Geant4/11.3.0/source/run/src/G4RunManager.cc:379
#10 0x00007fffc33984fe in G4RunManager::BeamOn (this=0x1e2eceb0, n_event=1, macroFile=0x0, n_select=-1)
    at /build/jenkins/workspace/lcg_release_pipeline/build/projects/Geant4-11.3.0/src/Geant4/11.3.0/source/run/src/G4RunManager.cc:266
#11 0x00007fffc08f2a56 in dd4hep::sim::Geant4UIManager::start (this=0x1d18b390) at /build/jenkins/workspace/lcg_nightly_pipeline/build/frameworks/DD4hep-HEAD/src/DD4hep/HEAD/DDG4/src/Geant4UIManager.cpp:253
#12 0x00007fffc08f2274 in dd4hep::sim::Geant4UIManager::operator() (this=0x1d18b390)
    at /build/jenkins/workspace/lcg_nightly_pipeline/build/frameworks/DD4hep-HEAD/src/DD4hep/HEAD/DDG4/src/Geant4UIManager.cpp:176
#13 0x00007fffc085b1bd in dd4hep::sim::Geant4Exec::run (kernel=...) at /build/jenkins/workspace/lcg_nightly_pipeline/build/frameworks/DD4hep-HEAD/src/DD4hep/HEAD/DDG4/src/Geant4Exec.cpp:645
#14 0x00007fffc089ab19 in dd4hep::sim::Geant4Kernel::run (this=0xd7e99f0) at /build/jenkins/workspace/lcg_nightly_pipeline/build/frameworks/DD4hep-HEAD/src/DD4hep/HEAD/DDG4/src/Geant4Kernel.cpp:409

(gdb) print aTrack
$18 = (const G4Track &) @0xaf614b60: {fPosition = {static ToleranceTicks = 100, data = {-0.93188089097621796, -1.0151686006325908, 1.1983657070238296}}, fGlobalTime = 0.0060933996082210735, 
  fLocalTime = 0.0060933996082210735, fTrackLength = 0, fVelocity = 299.70327308296203, fpTouchable = {fObj = 0xaf615b60}, fpNextTouchable = {fObj = 0xaf615b60}, fpOriginTouchable = {fObj = 0xaf615b60}, 
  fpDynamicParticle = 0x1e96ba50, fTrackStatus = fAlive, fStepLength = 1.826211830661594, fWeight = 1, fpStep = 0x1e56e760, fVtxPosition = {static ToleranceTicks = 100, data = {0, 0, 0}}, 
  fVtxMomentumDirection = {static ToleranceTicks = 100, data = {-0.51028083124328183, -0.55588764873181384, 0.65620301374885559}}, fVtxKineticEnergy = 71074.08009139348, fpLVAtVertex = 0x23d74730, 
  fpCreatorProcess = 0x0, fpUserInformation = 0x0, prev_mat = 0x0, groupvel = 0x0, prev_velocity = 0, prev_momentum = 0, fpAuxiliaryTrackInformationMap = 0x0, fCurrentStepNumber = 1, fCreatorModelID = -1, 
  fParentResonanceDef = 0x0, fParentResonanceID = 0, fParentID = 0, fTrackID = 1, fBelowThreshold = false, fGoodForTracking = false, is_OpticalPhoton = false, useGivenVelocity = false, fCopyTouchables = true}
(gdb) print *(aTrack.fpDynamicParticle)
$19 = {theMomentumDirection = {static ToleranceTicks = 100, data = {-0.51028065066499584, -0.55588785790780348, 0.65620297697250818}}, thePolarization = {static ToleranceTicks = 100, data = {0, 0, 0}}, 
  theParticleDefinition = 0x1e6028e0, theElectronOccupancy = 0x0, thePreAssignedDecayProducts = 0x1dfd2c60, primaryParticle = 0xaf6046d0, theKineticEnergy = 71074.080012577484, 
  theLogKineticEnergy = 1.7976931348623157e+308, theBeta = -1, theProperTime = 0.00014861689118864601, theDynamicalMass = 1776.8199999996934, theDynamicalCharge = -1, theDynamicalSpin = 0.5, 
  theDynamicalMagneticMoment = -1.6666182458776762e-11, thePreAssignedDecayTime = 0.00014857268126126702, verboseLevel = 1, thePDGcode = 0}

thePreAssignedDecayTime = 0.00014857268126126702
vs.
theProperTime           = 0.00014861689118864601

The decay happens too late?

[zwu0922]

in addition, I think that the crossing angle boost applied in ddsim also affects the taus' decay points ?

Yes, but that is not enabled in this case. Vertex Smearing would also change the position.

Hi Andre, I have one related question. If I would like to obtain a more realistic full simulation, I should turn on the 15 mrad crossing angle boost, as well as smear the vertex by vertex sigma_x/y/z/t in ddsim, right?

I found the documentation of FCC-ee vertex distribution here.

[andresailer]

Yes, for more realism you need to enable crossing angle boost and vertex smearing. But it is easier to validate whether things are working correctly without adding additional effects. So it depends on what you want to study.

[andresailer]

I submitted a ticket to geant4 about this https://bugzilla-geant4.kek.jp/show_bug.cgi?id=2645