PhysicalVolumeInfoCollection

This page page needs expert review!

Actually, the definition of a data product is slightly broader than this. The art::Run object is just an art::RunId object plus a collection of data products; similarly for the art::SubRun object. An example of a data product in the Run record is PhysicalVolumeInfoCollection. When we intialize Geant4, we do it in the beginRun method of Mu2eG4/src/G4_plugin.cc. At the end of Geant4 initialization we create a std::vector of all physical volumes known to G4 and we put this information into the art::Run object as a PhysicalVolumeInfoCollection. The SimParticle class holds two indices into this collection; one describes the volume in which the particle was born and the other describes the volume in which the particle stopped.

SimParticle volume number is the index in PhysicalVolumeHelper StepPointMC's record only the copy number for the volume.

The components are:

• PhysicalVolumeInfo - a volume text name and material name. It also contains the copy number for volumes which are repeated, such as crystals.
• PhysicalVolumeInfoCollection - a vector of PhysicalVolumeInfo
• PhysicalVolumeInfoSingleStage - a cet::map_vector of PhysicalVolumeInfo, only the PVI that are used by SimParticles. The map_vector index is a counter over the geant volume store.
• PhysicalVolumeInfoMultiCollection - a vector of PhysicalVolumeInfoSingleStage

The PhysicalVolumeInfoMultiCollection is needed because different stages of a simulation might use completely different geometries, which have different numbers for the volumes.

• Mu2eG4/src/PhysicalVolumeHelper holds full list of volumes as geant pointers, list of PV's for a single stage, and converts geant tracks to an index in the volume list.
• Mu2eG4/src/Mu2eG4_module.cc creates PhysicalVolumeHelper, fills with all volumes at begin run from geant PhysicalVolumeStore, creates PhysicalVolumeInfoMultiCollection in beginSubRun - copies existing, adds new from PhysicalVolumeHelper for current stage
• CompressPhysicalVolumes_module.cc
  • in event: saves the set of volumes used by input SimParticles and SimParticles pointed to by StepPointMC's
  • in subrun:

Issues

• the PVIMC are added to each SubRun. As files are concatenated, the products start to pile up. After skimming a large sample (order a million) SubRuns to a single file, it can take up a few GB of space.
• in mixing, only the particles themselves are imported and the PVIMC are not transferred to the output. This means a mixed SimParticle's volumes cannot be interpreted except by manipulation of the collections out side of art processing. Also the SimParticles from each mixed-in sample may have duplicates so the SimParticles are renumbered, complicating the problem (but in a deterministic way). If the mixing job includes simulation new PVIMC will be added which may or may not be appropriate for the mixed particles.
• in the compression of calorimeter StepPointMC's into CaloShowerSteps, the code needs to know what SimParticles are inside or outside the calorimeter so the volume information must be present. This means compression can't be run on a mixed sample, only a sample with the PVIMC of all SimParticles. This implies compression must be run before mixing.

Plans

From discussions around 3/2018.

• Produce a PhysicalVolumeInfoCollection at the beginning of every simulation job. Compute a store a hash and make the hash accessable to other modules. Write the full list to the BeginRun record, with the hash. When files are concatenated, art will recognize:
  • the products are identical
  • they all represent the entire run (as opposed to fragment of the run)

and write only one copy of the product to the output file. (It will actually also write records of the existence of the other copies, but that takes no space and will be dropped on further read/write cycles.)

• add a integer to the SimParticle which is the hash of the PhysicalVolumeInfoCollection. This would be filled when the SimParticle is created. In this way, every SimParticle can be unambiguously tied to a geometry. (Alternatively, the current pattern of SimParticle numbers for each stage can be continued to be tied to a geometry as in the PVIMC.)