source: trunk/documents/UserDoc/DocBookUsersGuides/ForApplicationDeveloper/xml/Detector/geomLogical.xml @ 905

<!-- ******************************************************** -->
<!--                                                          -->
<!--  [History]                                               -->
<!--    Converted to DocBook: Katsuya Amako, Aug-2006         -->
<!--    Changed by: Gabriele Cosmo, 18-Apr-2005               -->
<!--                                                          -->
<!-- ******************************************************** -->


<!-- ******************* Section (Level#2) ****************** -->
<sect2 id="sect.Geom.LogVol">
<title>
Logical Volumes
</title>

<para>
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.
</para>

<para>
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.
</para>

<para>
A Logical Volume also manages the information relative to the
Visualization attributes (<xref linkend="sect.VisAtt" />) and 
user-defined parameters related to tracking, electro-magnetic field
or cuts (through the <literal>G4UserLimits</literal> interface).
</para>

<para>
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.

<informalexample>
<programlisting>
    G4LogicalVolume( G4VSolid*             pSolid,
                     G4Material*           pMaterial,
                     const G4String&amp;       Name,
                     G4FieldManager*       pFieldMgr=0,
                     G4VSensitiveDetector* pSDetector=0,
                     G4UserLimits*         pULimits=0,
                     G4bool                Optimise=true )
</programlisting>
</informalexample>
</para>

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

<informalexample>
<programlisting>
    G4double GetSmartless() const
    void SetSmartless(G4double s)
</programlisting>
</informalexample>

The default <emphasis>smartless</emphasis> value is <emphasis>2</emphasis>
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 <emphasis>2</emphasis> through the following UI
run-time command:
<informalexample>
<programlisting>
    /run/verbose 2
</programlisting>
</informalexample>
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.
</para>

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

<informalexample>
<programlisting>
    G4double GetMass(G4bool forced=false)
</programlisting>
</informalexample>
</para>

<para>
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 <literal>true</literal> for the boolean argument 
<literal>forced</literal> in input. 
Computation should be forced if the geometry setup has
changed after the previous call.
</para>

<para>
Finally, the Logical Volume manages the information relative to
the Envelopes hierarchy required for fast Monte Carlo
parameterisations (<xref linkend="sect.PhysProc.Param" />).
</para>


<!-- ******************* Section (Level#3) ****************** -->
<sect3 id="sect.Geom.LogVol.SubReg">
<title>
Sub-detector Regions
</title>

<para>
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 <emphasis>cuts</emphasis> to each of these detector
parts. This allows a more detailed simulation to occur only in
those regions where it is required.
</para>

<para>
The concept of detector <emphasis>Region</emphasis> was 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:

<informalexample>
<programlisting>
    G4Region( const G4String&amp; rName )
</programlisting>
</informalexample>

where:

<informaltable>
<tgroup cols="2">
  <tbody>
  <row>
    <entry>
      <literal>rName</literal>
    </entry>
    <entry>
      String identifier for the detector region
    </entry>
  </row>
  </tbody>
</tgroup>
</informaltable>
</para>

<para>
A <literal>G4Region</literal> must then be assigned to a logical volume,
in order to make it a <emphasis>Root Logical Volume</emphasis>:

<informalexample>
<programlisting>
    G4Region* emCalorimeter = new G4Region("EM-Calorimeter");
    emCalorimeter-&gt;AddRootLogicalVolume(emCalorimeter);
</programlisting>
</informalexample>
</para>

<para>
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.
</para>

<para>
A specific <emphasis>Production Cut</emphasis> can be assigned to the region,
by defining and assigning to it a <literal>G4ProductionCut</literal>
object

<informalexample>
<programlisting>
    emCalorimeter-&gt;SetProductionCuts(emCalCuts);
</programlisting>
</informalexample>
</para>

<para>
<xref linkend="sect.ProThres.Set" /> 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 
<emphasis>one</emphasis> 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.
</para>


</sect3>
</sect2>