Closed chekanov closed 6 years ago
Can you please post the command that produces this, you call ddsim?
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
I think part of the problems are the particles with generator status > 3, and maybe also #226
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: https://github.com/AIDASoft/DD4hep/blob/550a98fc9f413a7071c520caf7173595c4327f3f/DDG4/examples/particle.tbl#L140-L141
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.
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?
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 https://github.com/AIDASoft/DD4hep/issues/226)?
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.
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 https://github.com/AIDASoft/DD4hep/issues/226
In SLIC, do you set the "particle.tbl" pdg file?
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
Ok. Can you post the slic output.slcio file as well, please. I am wondering what SLIC does with the MC record.
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
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)
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...
I think Slic and ddsim use different StdhepReaders for LCIO - see here: https://github.com/iLCSoft/LCIO/issues/8.
Fixed by #232
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:
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