Project

General

Profile

Statusworking meeting 2162012

Philippe -
excluding initialization. 100 events.
performance 72% in geometry.so and process.so, rest is particle.so, track.so, clhep.so?
math library - 64/360 = 18% ?
process.so is ... transport.

How does this compare to CMSSW? (ask Krzysztof about this)
Profiling results of cmssw appplication can be found at
http://oink.fnal.gov/perfanalysis/g4p/g4.9.4_cmssw426_73/
which shows consistent the result what Philippe reports.

Soon -
G4Tracks are hard to write out. momentum + position + type + touchable_history.
Problem is putting the G4Track back into the system - also has dynamic particle.

We looked at lots of G4 classes to decide what to do about feeding the particles (primaries and secondaries) back into the system after the physics run. Here is what we decided to try.

Save tracks into a text file with all necessary information during the physics run, this information must include the track length.
Also save all the step information for all the tracks, so we can study the step lengths and add this information to the no-physics run.
Derive a new class from G4PrimaryParticle called G4FixedPrimaryParticle that adds track length.
Look at the G4ParticleGun and create a new G4VPrimaryGenerator called G4Shotgun.
The G4Shotgun will read all the track information from the text file, create one G4FixedPrimaryParticle for each particle in file, add it to the G4Event with a unique vertex.

The DynamicParticle appears to have a pointer to the G4VPrimaryParticle, which should really be the G4FixedPrimaryParticle.

The new G4TrackKiller process will look at the G4FixedPrimaryParticle from the DynamicParticle of the G4Track. It can use this information to kill the track at the correct position.