Logical Volumes

The Logical Volume manages the information associated with detector elements represented by a given Solid and Material, independently from its physical position in the detector.

G4LogicalVolumes must be allocated using ‘new’ in the user’s program; they get registered to a G4LogicalVolumeStore at construction, which will also take care to deallocate them at the end of the job, if not done already in the user’s code.

A Logical Volume knows which physical volumes are contained within it. It is uniquely defined to be their mother volume. A Logical Volume thus represents a hierarchy of unpositioned volumes whose positions relative to one another are well defined. By creating Physical Volumes, which are placed instances of a Logical Volume, this hierarchy or tree can be repeated.

A Logical Volume also manages the information relative to the Visualization attributes (Visualization Attributes) and user-defined parameters related to tracking, electro-magnetic field or cuts (through the G4UserLimits interface).

By default, tracking optimization of the geometry (voxelization) is applied to the volume hierarchy identified by a logical volume. It is possible to change the default behavior by choosing not to apply geometry optimization for a given logical volume. This feature does not apply to the case where the associated physical volume is a parameterised volume; in this case, optimization is always applied.

G4LogicalVolume( G4VSolid*             pSolid,
                 G4Material*           pMaterial,
                 const G4String&       Name,
                 G4FieldManager*       pFieldMgr=0,
                 G4VSensitiveDetector* pSDetector=0,
                 G4UserLimits*         pULimits=0,
                 G4bool                Optimise=true )

Note

Geant4 does not impose any restriction on the name assigned to logical volumes; names can be shared. It is however good practice to specify unique names for each logical volume, to allow for easier retrivial from stores for post-processing use.

Through the logical volume it is also possible to tune the granularity of the optimisation algorithm to be applied to the sub-tree of volumes represented. This is possible using the methods:

G4double GetSmartless() const
void SetSmartless(G4double s)

The default smartless value is 2 and controls the average number of slices per contained volume which are used in the optimisation. The smaller the value, the less fine grained optimisation grid is generated; this will translate in a possible reduction of memory consumed for the optimisation of that portion of geometry at the price of a slight CPU time increase at tracking time. Manual tuning of the optimisation is in general not required, since the optimal granularity level is computed automatically and adapted to the specific geometry setup; however, in some cases (like geometry portions with ‘dense’ concentration of volumes distributed in a non-uniform way), it may be necessary to adopt manual tuning for helping the optimisation process in dealing with the most critical areas. By setting the verbosity to 2 through the following UI run-time command:

/run/verbose 2

a statistics of the memory consumed for the allocated optimisation nodes will be displayed volume by volume, allowing to easily identify the critical areas which may eventually require manual intervention.

The logical volume provides a way to estimate the mass of a tree of volumes defining a detector or sub-detector. This can be achieved by calling the method:

G4double GetMass(G4bool forced=false)

The mass of the logical volume tree is computed from the estimated geometrical volume of each solid and material associated with the logical volume and its daughters. Note that this computation may require a considerable amount of time, depending on the complexity of the geometry tree. The returned value is cached by default and can be used for successive calls, unless recomputation is forced by providing true for the Boolean argument forced in input. Computation should be forced if the geometry setup has changed after the previous call.

Finally, the Logical Volume manages the information relative to the Envelopes hierarchy required for fast Monte Carlo parameterisations (Parameterisation).

Sub-detector Regions

In complex geometry setups, such as those found in large detectors in particle physics experiments, it is useful to think of specific Logical Volumes as representing parts (sub-detectors) of the entire detector setup which perform specific functions. In such setups, the processing speed of a real simulation can be increased by assigning specific production cuts to each of these detector parts. This allows a more detailed simulation to occur only in those regions where it is required.

The concept of detector Region is introduced to address this need. Once the final geometry setup of the detector has been defined, a region can be specified by constructing it with:

G4Region( const G4String& rName )

where:

rName

String identifier for the detector region

G4Regions must be allocated using ‘new’ in the user’s program; they get registered to a G4RegionStore at construction, which will also take care to deallocate them at the end of the job, if not done already in the user’s code.

A G4Region must then be assigned to a logical volume, in order to make it a Root Logical Volume:

G4Region* emCalorimeter = new G4Region("EM-Calorimeter");
emCalorimeterLV->SetRegion(emCalorimeter);
emCalorimeter->AddRootLogicalVolume(emCalorimeterLV);

A root logical volume is the first volume at the top of the hierarchy to which a given region is assigned. Once the region is assigned to the root logical volume, the information is automatically propagated to the volume tree, so that each daughter volume shares the same region. Propagation on a tree branch will be interrupted if an already existing root logical volume is encountered.

Note

It is recommended to assign unique names to logical volumes specified as root logical volumes, as this will guarantee proper retrievial from the store for post-processing use in persistency. The same applies for names assigned to regions.

A specific Production Cut can be assigned to the region, by defining and assigning to it a G4ProductionCut object

emCalorimeter->SetProductionCuts(emCalCuts);

Set production threshold (SetCut methods) describes how to define a production cut. The same region can be assigned to more than one root logical volume, and root logical volumes can be removed from an existing region. A logical volume can have only one region assigned to it. Regions will be automatically registered in a store which will take care of destroying them at the end of the job. A default region with a default production cut is automatically created and assigned to the world volume.

Regions can also become ‘envelopes’ for fast-simulation; can be assigned user-limits or generic user-information (G4VUserRegionInformation); can be associated to specific stepping-actions (G4UserSteppingAction) or have assigned a local magnetic-field (local fields specifically associated to logical volumes take precedence anyhow).