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.
G4LogicalVolume
s 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:
|
String identifier for the detector region |
G4Region
s 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).