Add generic hit/step structure for Geant4 integration

[celeritas-project]

Add generic hit/step structure for Geant4 integration

[whokion]

Okay, I now understood the motivation of providing an intermediate data to users (which you mentioned several times before, but which I forgot). For the moment, please see some of example Hits (data members) from CMSSW
https://cmssdt.cern.ch/lxr/source/SimDataFormats/CaloHit/interface/PCaloHit.h
https://cmssdt.cern.ch/lxr/source/SimDataFormats/TrackingHit/interface/PSimHit.h
which may be two relevant (simulation) SD hit classes for now.
Information need for the VI's EM benchmark should be discussed in a different context as those analysis can be done with our diagnostics output (i.e., rather close to MC truth information) or during user actions. So, I guess that there may be three separate topics now, 1) data format of sensitive detector hits and how to handle them from the celeritas side, 2) data format of MC truth which @stognini already covered in his talk and 3) data format for common benchmark which may be a combination or subset of 1) and 2), which we can definitely discuss more at our weekly meeting and further discuss with the Adept team later for an agreement.

[sethrj]

Restrict the scope of this to focus on the immediate need of the experiment frameworks we might need to integrate with.

[sethrj]

@whokion Maybe a good initial target for this goal would be all the hit data that Geant4 can supply? We could start by supporting filtering tracks based on the detector volume (i.e. only store hits for the sensitive detectors). Can you list all the data that would be needed to reconstruct a Geant4 "hit" object?

[whokion]

@sethrj As you many know that Geant4 does not define any hit structure, but only provides G4VHit.hh (pure virtual). So, a concrete hit class and an associated sensitive detector should be created by the user based on G4Step (link to almost all low level tracking information) and G4TouchableHistory (geometry information) - therefore based on necessary Views for the celertias case. For an example, please see their combination at https://github.com/celeritas-project/acceleritas/blob/master/app/g4hpc/include/CalorimeterHit.hh and https://github.com/celeritas-project/acceleritas/blob/master/app/g4hpc/src/CalorimeterSD.cc#L34 (i.e, a concrete implementation of G4VSensitiveDetector::ProcessHits as an example). Then, the final output data is a collection of G4THitsCollection classes for all SensitiveDetectors and probably additional Event, Run and auxiliary information which can be stored in an event head bank (if data unit is an event). Normally particle ID and trackID are not parts of hit information as they can not be known during data collection period (i.e., during real data taking). Therefore, the list of hit data members should be from each experiment depending on what data can be collected from their detectors and used for digitization. Therefore, there is no single definition of 'calorimeter hit' as all experiments may have different variation of their calorimeters and data definitions (of which their detectors can actually collect).

So regarding to Vladimir Ivantchenko's comments, we need know CMS calorimeter hit information (from CMSSW) or ATLAS hit information (from Athena) if we want to construct calorimeter hits for their (simulation) digitization processes. Similar for their tracker hit definitions and so on. As I mentioned more than a couple of times (but might not explain clearly enough?), we, as a toolkit developer, need to provide only necessary virtual interfaces (in the Geant4 case, they are G4VHit, G4THitsCollection, G4VSensitiveDetector) and something like G4VUserDetectorConstruction::ConstructSDandField - then, user applications (something like our demo-loop) will add specific hit classes depending on specific user detectors or their data collection structure. Sorry for repeating a long story for the SD discussion that you may already know, but I want to make sure that we clear separate what components should be inside the celeritas source and what others should go under the application area (i.e., user responsibility). Anyway, we may start with a something simple like CalorimeterHit in the acceleritas example for any foreseeable our test cases which can be easily expandable later.

[sethrj]

Ahh, I had forgotten and was thinking of G4Step and G4StepChange. Thank you for the detailed explanation.

I know you've mentioned the virtual interfaces before, but the truth is that for users to write a "virtual interface" it will require them to write a kernel, manage data transfers, etc. I was hoping that to first order we might be able to have a couple of "out of the box" options for collecting data that could even hook up to their existing hit interfaces. That way even though their initial implementation might be far from optimal performance-wise, it would at least open a door to getting started.

With Acceleritas, would it be possible for us to reconstruct Geant4 step data to pass to existing sensitive detector routines in user code? If we know what data the user requires, and a few filtering criteria, we could perhaps reconstruct step information for those data and fill the unneeded bits with dummy values. At the meeting today maybe we could talk about what data is needed for some of VI's EM benchmark problems.

[sethrj]

Prerequisite: #539

The initial implementation of this will be an "easy but inefficient" way to hook into other frameworks. To first order we'll create a StepInterface subclass:

• Input is a vector of G4VSensitiveDetector* (or list of logical volumes or list of names?) plus a StepSelection object with the list of components needed
• We construct a map of logical volume name (Label::from_geant) to sensitive detector, probably an array to be easy (VecGeom logical volume ID maps to Celeritas VolumeId)
• For now let's be dumb and copy everything over to host

Future optimizations:

• device->host copy doesn't reallocate?
• do volume filtering on host