Reading STDHEP file created from Pythia8

[chekanov]

Hi,

I have a problem reading STDHEP file from Pythia8. This file is here:

http://atlaswww.hep.anl.gov/asc/tmp/Output_TRUTH.stdhep

dd4hep gives many warnings about unknown generator status (71). I guess this is ok, but then it simply stops after 1st event (some infinite loop?), with the message:

### G4EmSaturation::FindBirksCoefficient Birks coefficient for G4_POLYSTYRENE  0.07943 mm/MeV

When I create STDHEP file from Pythia6, everything woks ok.

I use ILCSOFT=/cvmfs/clicdp.cern.ch/iLCSoft/builds/2017-08-23/x86_64-slc6-gcc62-opt and CLIC_o3_v13

best, Sergei

[petricm]

Can you please post the command that produces this, you call ddsim?

[chekanov]

Here is the command on lxplus:

source  /cvmfs/clicdp.cern.ch/compilers/gcc/6.2.0/x86_64-slc6/setup.sh
ILCSOFT=/cvmfs/clicdp.cern.ch/iLCSoft/builds/2017-08-23/x86_64-slc6-gcc62-opt
source $ILCSOFT/init_ilcsoft.sh
ddsim --steeringFile /cvmfs/clicdp.cern.ch/iLCSoft/builds/2017-08-23/x86_64-slc6-gcc62-opt/ClicPerformance/HEAD/examples/clic_steer.py \
      --compactFile /cvmfs/clicdp.cern.ch/iLCSoft/builds/2017-08-23/x86_64-slc6-gcc62-opt/lcgeo/HEAD/CLIC/compact/CLIC_o3_v13/CLIC_o3_v13.xml \
      --inputFile  Output_TRUTH.stdhep \
      --outputFile  output.slcio \
      --numberOfEvents 2

best, Sergei

[andresailer]

I think part of the problems are the particles with generator status > 3, and maybe also #226

[andresailer]

There is also a particle in the event list with PDG "-513" which has no lifetime in the extra particle file we are using, but it has a lifetime and pre-assigned decay in the first event which causes the infinite loop in the simulation step:

DD4hep/DDG4/examples/particle.tbl

Lines 140 to 141 in 550a98f

	513 B*^0 0 5.32480 -1.00000 0.00000E+00
	-513 B*~^0 0 5.32480 -1.00000 0.00000E+00

[chekanov]

Hi,

Indeed, I've looked at this event using the original (smaller) promc file (used to make stdhep):

bash   #  set bash if you haven't done this before
wget http://atlaswww.hep.anl.gov/hepsim/soft/hs-toolkit.tgz -O - | tar -xz;
source hs-toolkit/setup.sh
wget http://mc.hep.anl.gov/asc/hepsim/events/ee/380gev/pythia8_ttbar_tunes/gev380ee_pythia8_ttbar_tune0_001.promc
hs-info gev380ee_pythia8_ttbar_tune0_001.promc 1 # prints 1st event

indeed it has

B*~^0  (-513)

on the line 95, that decays to B~^0. But tau0 is set to 0 by Pythia8. I also looked at ParticleData.xml, and there is no tau0 info for B*~^0. It assume it is set to zero in Pythia8.

[andresailer]

The MC record seems to be inconsistent, the endpoint of the PDG=-513 (index 95) is not the same as the vertex of its second daughter (the PDG=-511, index 174), instead they have the same endpoint up to the precision printed by lcio (which makes sense if -511 decays immediately). Index 173 has the same vertex as its parent.

index|      PDG ||gen| vertex x,     y   ,   z     | endpoint x,    y  ,   z     |    mass |  charge |[parents] - [daughters]
   95|      -513|| 2 | 0.00e+00, 0.00e+00, 0.00e+00|-2.13e+00,-1.39e+00, 7.28e-01| 5.33e+00| 0.00e+00|[90,91,92,93,94] - [173,174] 
  173|      -211|| 1 |-2.13e+00,-1.39e+00, 7.28e-01| 0.00e+00, 0.00e+00, 0.00e+00| 1.40e-01|-1.00e+00|[95] - [] 
  174|      -511|| 2 | 0.00e+00, 0.00e+00, 0.00e+00|-2.13e+00,-1.39e+00, 7.28e-01| 5.28e+00| 0.00e+00|[95] - [209,210,211] 

(from dumpevent after stdhepjob, cropped the particle momenta and some other non-pertinent information).

Could it be that your promc to stdhep introduces this effect?

[chekanov]

This converter works perfectly well for Pythia6 and other Monte Carlo generators, it will be strange it fails on Pythia8. From the other hand, Pythia8 has somewhat different logic in organizing the particle event list. The converter itself is in http://atlaswww.hep.anl.gov/hepsim/soft/rfull210.tgz
The file: in the directory "ilcsoft/rfull210/promc2other/promc2stdhep.java
(based on StdhepConverter from Tony).

Unfortunately, an alternative converter (promc2lcio) cannot be used now, since DD4HEP does not take
LCIO files with MCParticle tables as inputs. Maybe, instead of spending time on the STDHEP converter, one can fix LCIO reader (see #226)?

[andresailer]

Given the problem I pointed out in the MC record, I don't think there is anything to be done on the dd4hep side. If it is not the converter then it might be pythia8 itself.

Can you give a link to the slcio file after promc2lcio for the same file as the stdhep one, so we can see if the MC record is also broken there.

[chekanov]

Yes, here is the link to the LCIO file with MCparticle:
http://atlaswww.hep.anl.gov/asc/tmp/gev380ee_pythia8_ttbar_tune0_001.slcio
This file works OK for CLIC-SiD and any SLIC-simulations. DD4HEP fails to read it due to the issue in #226

[andresailer]

In SLIC, do you set the "particle.tbl" pdg file?

[chekanov]

Yes, we use slic 5.1 from github (based on geant4 10.3.1). We call it as

slic -P ${SLIC_DIR}/data/particle.tbl -x -i <input>.lcio -g .. etc

best, Sergei

[andresailer]

Ok. Can you post the slic output.slcio file as well, please. I am wondering what SLIC does with the MC record.

[chekanov]

Ok, here is the file done with CLIC-SID and SLIC 5.1 (2 events only)

http://atlaswww.hep.anl.gov/asc/tmp/gev380ee_pythia8_ttbar_tune0_001.slcio

best, Sergei

[chekanov]

Just to add. If Slic is initialized from the external MAC file where the crossing angle is given,
I do see this problem:

Set Lorentz transformation angle to 7 mrad
G4VUserPhysicsList::PreparePhysicsTable  : No Process Manager for B*^+
B*^+ should be created in your PhysicsList

But we do not use this initialization any more (i.e. it is done inside slic)

[andresailer]

Well, the MCParticle collection in the SLIC file is different than the one I get from the stdhep file (after stdhepjob) What is Index=173 (PDG=211) after stdhepjob is 172 in SLIC. Also, in the this file the daughters of PDG=513 are 511 and 22, which probably makes more sense as it conserves charge...

From the SLIC file

   94|      -513|-3.79e+01,-5.43e+00,-6.02e+00|-3.79e+01,-5.43e+00,-6.02e+00| 3.92e+01| 2 |[   t    ]| 0.00e+00, 0.00e+00, 0.00e+00|-1.06e-305,-1.52e-306,-1.68e-306| 5.33e+00| 0.00e+00| 0.00e+00, 0.00e+00, 0.00e+00|  (0, 0)   | [89,90,91,92,93] - [173,174] 
  172|      -211|-1.02e+00,-1.10e+00, 2.56e-01| 0.00e+00,-0.00e+00, 0.00e+00| 1.53e+00| 1 |[  v c s ]|-2.12e+00,-1.40e+00, 7.32e-01|-6.12e+00,-1.34e+03, 2.42e+02| 1.40e-01|-1.00e+00| 0.00e+00, 0.00e+00, 0.00e+00|  (0, 0)   | [84] - [596] 
  173|      -511|-3.76e+01,-5.33e+00,-5.96e+00|-3.76e+01,-5.33e+00,-5.96e+00| 3.88e+01| 2 |[  vt    ]|-1.06e-305,-1.52e-306,-1.68e-306|-1.74e+00,-2.47e-01,-2.76e-01| 5.28e+00| 0.00e+00| 0.00e+00, 0.00e+00, 0.00e+00|  (0, 0)   | [94] - [209,210,211] 
  174|        22|-3.50e-01,-9.55e-02,-6.11e-02|-0.00e+00,-0.00e+00,-0.00e+00| 3.68e-01| 1 |[  v c s ]|-1.06e-305,-1.52e-306,-1.68e-306|-1.27e+03,-3.47e+02,-2.22e+02| 0.00e+00| 0.00e+00| 0.00e+00, 0.00e+00, 0.00e+00|  (0, 0)   | [94] - [] 

From the other file

   95|      -513|-3.82e+01,-5.43e+00,-6.02e+00| 0.00e+00, 0.00e+00, 0.00e+00| 3.94e+01| 2 |[    0   ]| 0.00e+00, 0.00e+00, 0.00e+00|-2.13e+00,-1.39e+00, 7.28e-01| 5.33e+00| 0.00e+00| 0.00e+00, 0.00e+00, 0.00e+00|  (0, 0)   | [90,91,92,93,94] - [173,174] 
  173|      -211|-1.03e+00,-1.10e+00, 2.55e-01| 0.00e+00, 0.00e+00, 0.00e+00| 1.53e+00| 1 |[    0   ]|-2.13e+00,-1.39e+00, 7.28e-01| 0.00e+00, 0.00e+00, 0.00e+00| 1.40e-01|-1.00e+00| 0.00e+00, 0.00e+00, 0.00e+00|  (0, 0)   | [95] - [] 
  174|      -511|-3.79e+01,-5.33e+00,-5.96e+00| 0.00e+00, 0.00e+00, 0.00e+00| 3.91e+01| 2 |[    0   ]| 0.00e+00, 0.00e+00, 0.00e+00|-2.13e+00,-1.39e+00, 7.28e-01| 5.28e+00| 0.00e+00| 0.00e+00, 0.00e+00, 0.00e+00|  (0, 0)   | [95] - [209,210,211] 

In this file the first two lines are

[00000004]    0|        90| 0.00e+00, 0.00e+00, 0.00e+00| 0.00e+00, 0.00e+00, 0.00e+00| 3.80e+02| 11 |[    0   ]| 0.00e+00, 0.00e+00, 0.00e+00| 0.00e+00, 0.00e+00, 0.00e+00| 3.80e+02| 0.00e+00| 0.00e+00, 0.00e+00, 0.00e+00|  (0, 0)   | [] - []
[00000005]    1|        11| 0.00e+00, 0.00e+00, 1.90e+02| 0.00e+00, 0.00e+00, 0.00e+00| 1.90e+02| 4 |[    0   ]| 0.00e+00, 0.00e+00, 0.00e+00| 0.00e+00, 0.00e+00, 0.00e+00| 5.10e-04|-1.00e+00| 0.00e+00, 0.00e+00, 0.00e+00|  (0, 0)   | [] - [6]

While SLIC does not have the line first line with PDG=90. Something seems to mess with the MCRecord...

[gaede]

I think Slic and ddsim use different StdhepReaders for LCIO - see here: iLCSoft/LCIO#8.

[andresailer]

Fixed by #232