Status meeting March 9th, 2012¶
Status of reading the trajectory samples in cmsExp (result of profiling)¶
Philippe ran the no-physics case with 1000 events from cmsExp. The profiling showed that G4Navigator::LocateGlobalPointAndSetup was taken proportionally much more time. Soon tracked it down to the necessary creation of the touchable object (which needs to known which volume they are in). In regular cmsExp, this is avoided by simply copying the parent's touchable handle.
In order to speed this up we would need to also store the vertex information (mainly on the parentage of the secondary).
Is there a way to 'uniquely' identify a volume?
It does not look like there is.
Update extracting equation of motion code from cmsExp/Geant4¶
Soon: I have been playing with CUDA a little bit. When we have a bundle of tracks send to the GPU we also need to send some equivalent to the touchable handle. I have written CUDA that send the magnetic fields and some information of the track. It is plugged into cmsExp. Sending geometry is the next big item.
Philippe created a patch Geant4 that extracts/copy the input to the G4MagErrorStepper__Stepper and I created a standalone program that can read this input and run ALL the geant4 code and cmsExpt that is called by G4MagErrorStepper__Stepper. I am planning on using this to test CUDA. profiling shows that 1/2 of the processing time is spend in looking up the magnetic field.
The prototype is currently at cluck:~pcanal/work/mag. It can be built via 'make' and executed by calling the resulting executable ('mag') which as built expects a data file named magErrorStepper.dat. This file can be created by applying the patch ~pcanal/work/mag/G4_extractStepperData.diff.
Next: Port the standalone example to CUDA. Search for algorithm implementing the same goal in a CUDA friendly way.