Content Skeleton

This Page

Previous topic

Chroma/NuWa/Geant4 Integration with ZeroMQ

Next topic

Chroma CUDA Photon handling

Chroma NuWa Integration


GPU hit creation maybe a step too far, as stepping too close to areas of detector custom code.

  • perhaps just transport the OPs and hand back to G4 as about to hit sensitive detectors ?
  • OR creating hits (times and charges)

Look into the nature of G4/DetSim “hits”, how difficult to take it to that level ? Wherever the handover happens, the approach to material/solid identity on the mesh needs to be understood

Geant4/DetSim reminder

(gdb) b 'DsPmtSensDet::ProcessHits(G4Step*, G4TouchableHistory*)'
Breakpoint 2 at 0xb472d1f8: file ../src/, line 324.
  • works out the volume, determines QE, knarly QE diddling, hit creation

    • not impossible to duplicate,

    • BUT disadvantage is mixing detector specific diddling with OP acceleration

      • maybe split stage, to keep detector specifics separate
[blyth@cms01 src]$ pwd
[blyth@cms01 src]$ grep ProcessHits *.cc DsPmtSensDet::ProcessHits(G4Step* step,        error() << "ProcessHits: step has no or empty touchable history" << endreq; DsRpcSensDet::ProcessHits(G4Step* step,      error() << "ProcessHits: step has no or empty touchable history."
[blyth@cms01 src]$

DsPmtModel, associating PMT names to volumes:

04 #include "G4VFastSimulationModel.hh"
06 class G4LogicalVolume;
07 class G4Hooks;                  // opaque
09 class DsPmtModel : public G4VFastSimulationModel
10 {
11 public:
12     DsPmtModel(const G4String& name, G4Envelope* volume,
13                G4bool unique = false);
14     DsPmtModel(const G4String& name);
15     virtual ~DsPmtModel ();


how/when to give OP tracks back to G4/reconstruction code ?

Maybe DsOpGPUStackAction

  1. collect OP into fWaiting stack (similar to DsOpStackAction)
  2. at NewStage
  • make interesting-or-not judgement

  • translate OP G4Tracks into numpy arrays ready for Chroma/GPU

  • perform OP cohort external propagation on GPU

    • where to stop GPU propagation ? defined SD volume ?
  • translate back from numpy arrays diddling the waiting G4Tracks [where/access?]

    • NewStage invokes a reclassify stackManager->ReClassify(); giving access

      to all the tracks in the ClassifyNewTrack allowing diddling then like the photon reweighting of G4ClassificationOfNewTrack DsFastMuonStackAction::ClassifyNewTrack (const G4Track* aTrack)

  • resume the G4 tracks by returning as fUrgent, which should immediately proceed into sens det handling

    • how does SD/hit handover work /data/env/local/dyb/trunk/NuWa-trunk/dybgaudi/Simulation/DetSim/src/

how does G4 OP propagation end ?

translation of DYB solid geomety into surface tris

what about some magic optransport physics process ?

NO, as need to deal with the OP as a cohort, not individually. Physics processes act on individual OP.

OP collection and propagation, kicked off where ?

  • G4ClassificationOfNewTrack DsOpStackAction::ClassifyNewTrack (const G4Track* aTrack)

    • assigns fWaiting status to OP, causing collection of OP tracks in the waiting stack
  • status is flipped to proceed with OP propagation only for events deemed to be interesting

  • the judgement and kick-off happens in void DsOpStackAction::NewStage() which is invoked when the fUrgent stack is empty (ie everything other than the waiting tracks have been tracked) and fWaiting stack has entries

  • a similar structure seems good for GPU propagation

    • collect all the OP to benefit from massive parallelisation