| 1 | <html>
|
|---|
| 2 | <head>
|
|---|
| 3 | <title>ADG: Geometry</title>
|
|---|
| 4 | </head>
|
|---|
| 5 |
|
|---|
| 6 | <!-- Changed by: Gabriele Cosmo, 18-Apr-2005 -->
|
|---|
| 7 | <!-- $Id: geomLogical.html,v 1.3 2006/06/09 13:59:15 gcosmo Exp $ -->
|
|---|
| 8 | <!-- $Name: $ -->
|
|---|
| 9 | <body>
|
|---|
| 10 | <table WIDTH="100%"><TR>
|
|---|
| 11 | <td>
|
|---|
| 12 | <a href="../../../../Overview/html/index.html">
|
|---|
| 13 | <IMG SRC="../../../../resources/html/IconsGIF/Overview.gif" ALT="Overview"></a>
|
|---|
| 14 | <a href="geometry.html">
|
|---|
| 15 | <IMG SRC="../../../../resources/html/IconsGIF/Contents.gif" ALT="Contents"></a>
|
|---|
| 16 | <a href="geomSolids.html">
|
|---|
| 17 | <IMG SRC="../../../../resources/html/IconsGIF/Previous.gif" ALT="Previous"></a>
|
|---|
| 18 | <a href="geomPhysical.html">
|
|---|
| 19 | <IMG SRC="../../../../resources/html/IconsGIF/Next.gif" ALT="Next"></a>
|
|---|
| 20 | </td>
|
|---|
| 21 | <td ALIGN="Right">
|
|---|
| 22 | <font SIZE="-1" COLOR="#238E23">
|
|---|
| 23 | <b>Geant4 User's Guide</b>
|
|---|
| 24 | <br>
|
|---|
| 25 | <b>For Application Developers</b>
|
|---|
| 26 | <br>
|
|---|
| 27 | <b>Geometry</b>
|
|---|
| 28 | </font>
|
|---|
| 29 | </td>
|
|---|
| 30 | </tr></table>
|
|---|
| 31 | <br><br>
|
|---|
| 32 |
|
|---|
| 33 | <a name="4.1.3">
|
|---|
| 34 | <h2>4.1.3 Logical Volumes</h2></a>
|
|---|
| 35 |
|
|---|
| 36 | <p>
|
|---|
| 37 | The Logical Volume manages the information associated with detector elements
|
|---|
| 38 | represented by a given Solid and Material, independently from its physical
|
|---|
| 39 | position in the detector.
|
|---|
| 40 | </p>
|
|---|
| 41 | <p>
|
|---|
| 42 | A Logical Volume knows which physical volumes are contained within it. It is
|
|---|
| 43 | uniquely defined to be their mother volume. A Logical Volume thus represents
|
|---|
| 44 | a hierarchy of unpositioned volumes whose positions relative to one another
|
|---|
| 45 | are well defined. By creating Physical Volumes, which are placed instances of
|
|---|
| 46 | a Logical Volume, this hierarchy or tree can be repeated.
|
|---|
| 47 | </p>
|
|---|
| 48 | <p>
|
|---|
| 49 | A Logical Volume also manages the information relative to the Visualization
|
|---|
| 50 | attributes (<a href="../Visualization/attributes.html">Section 8.6</a>) and
|
|---|
| 51 | user-defined parameters related to tracking, electro-magnetic field or cuts
|
|---|
| 52 | (through the <tt>G4UserLimits</tt> interface).
|
|---|
| 53 | </p>
|
|---|
| 54 | <p>
|
|---|
| 55 | By default, tracking optimization of the geometry (voxelization) is applied
|
|---|
| 56 | to the volume hierarchy identified by a logical volume. It is possible to
|
|---|
| 57 | change the default behavior by choosing not to apply geometry optimization
|
|---|
| 58 | for a given logical volume. This feature does not apply to the case where the
|
|---|
| 59 | associated physical volume is a parameterised volume; in this case,
|
|---|
| 60 | optimization is always applied.
|
|---|
| 61 |
|
|---|
| 62 | <pre>
|
|---|
| 63 | G4LogicalVolume( G4VSolid* pSolid,
|
|---|
| 64 | G4Material* pMaterial,
|
|---|
| 65 | const G4String& Name,
|
|---|
| 66 | G4FieldManager* pFieldMgr=0,
|
|---|
| 67 | G4VSensitiveDetector* pSDetector=0,
|
|---|
| 68 | G4UserLimits* pULimits=0,
|
|---|
| 69 | G4bool Optimise=true )
|
|---|
| 70 | </pre>
|
|---|
| 71 | </p>
|
|---|
| 72 | <P>
|
|---|
| 73 | The logical volume provides a way to estimate the <I>mass</I> of a tree of
|
|---|
| 74 | volumes defining a detector or sub-detector. This can be achieved by calling
|
|---|
| 75 | the method:
|
|---|
| 76 | <PRE>
|
|---|
| 77 | G4double GetMass(G4bool forced=false)
|
|---|
| 78 | </PRE>
|
|---|
| 79 | The mass of the logical volume tree is computed from the estimated geometrical
|
|---|
| 80 | volume of each solid and material associated with the logical volume and its
|
|---|
| 81 | daughters. Note that this computation may require a considerable amount of
|
|---|
| 82 | time, depending on the complexity of the geometry tree.
|
|---|
| 83 | The returned value is cached by default and can be used for successive calls,
|
|---|
| 84 | unless recomputation is forced by providing <TT>true</TT> for the boolean
|
|---|
| 85 | argument <TT>forced</TT> in input. Computation should be forced if the
|
|---|
| 86 | geometry setup has changed after the previous call.</P>
|
|---|
| 87 | <P>
|
|---|
| 88 | Finally, the Logical Volume manages the information relative to the Envelopes
|
|---|
| 89 | hierarchy required for fast Monte Carlo parameterisations
|
|---|
| 90 | (<a href="../TrackingAndPhysics/physicsProcess.html#5.2.6">Section 5.2.6</a>).</P>
|
|---|
| 91 |
|
|---|
| 92 | <P> </P>
|
|---|
| 93 |
|
|---|
| 94 | <a name="4.1.3.1">
|
|---|
| 95 | <H4>4.1.3.1 Sub-detector Regions</H4></a>
|
|---|
| 96 |
|
|---|
| 97 | In complex geometry setups, such as those found in large detectors in
|
|---|
| 98 | particle physics experiments, it is useful to think of specific Logical
|
|---|
| 99 | Volumes as representing parts (sub-detectors) of the entire detector setup
|
|---|
| 100 | which perform specific functions. In such setups, the processing speed of
|
|---|
| 101 | a real simulation can be increased by assigning specific production
|
|---|
| 102 | <i>cuts</i> to each of these detector parts. This allows a more detailed
|
|---|
| 103 | simulation to occur only in those regions where it is required.
|
|---|
| 104 | <P>
|
|---|
| 105 | The concept of detector <i>Region</i> was introduced to address this need.
|
|---|
| 106 | Once the final geometry setup of the detector has been defined, a region
|
|---|
| 107 | can be specified by constructing it with:
|
|---|
| 108 | <PRE>
|
|---|
| 109 | G4Region( const G4String& rName )
|
|---|
| 110 | </PRE></P>
|
|---|
| 111 | <P>
|
|---|
| 112 | where:</P>
|
|---|
| 113 | <P>
|
|---|
| 114 | <table border=1 cellpadding=8>
|
|---|
| 115 | <td><tt>rName</tt> <td>String identifier for the detector region
|
|---|
| 116 | </table></P>
|
|---|
| 117 | <P>
|
|---|
| 118 | A <tt>G4Region</tt> must then be assigned to a logical volume, in order to
|
|---|
| 119 | make it a <i>Root Logical Volume</i>:
|
|---|
| 120 | <PRE>
|
|---|
| 121 | G4Region* emCalorimeter = new G4Region("EM-Calorimeter");
|
|---|
| 122 | emCalorimeter->AddRootLogicalVolume(emCalorimeter);
|
|---|
| 123 | </PRE>
|
|---|
| 124 | A root logical volume is the first volume at the top of the hierarchy to
|
|---|
| 125 | which a given region is assigned. Once the region is assigned to the root
|
|---|
| 126 | logical volume, the information is automatically propagated to the volume
|
|---|
| 127 | tree, so that each daughter volume shares the same region. Propagation on
|
|---|
| 128 | a tree branch will be interrupted if an already existing root logical
|
|---|
| 129 | volume is encountered.</P>
|
|---|
| 130 | <P>
|
|---|
| 131 | A specific <i>Production Cut</i> can be assigned to the region, by defining
|
|---|
| 132 | and assigning to it a <tt>G4ProductionCut</tt> object
|
|---|
| 133 | <PRE>
|
|---|
| 134 | emCalorimeter->SetProductionCuts(emCalCuts);
|
|---|
| 135 | </PRE>
|
|---|
| 136 | <a href="../TrackingAndPhysics/thresholdVScut.html#5.4.2">Section 5.4.2</a>
|
|---|
| 137 | describes how to define a production cut. The same region can be assigned
|
|---|
| 138 | to more than one root logical volume, and root logical volumes can be
|
|---|
| 139 | removed from an existing region. A logical volume can have only <i>one</i>
|
|---|
| 140 | region assigned to it. Regions will be automatically registered in a store
|
|---|
| 141 | which will take care of destroying them at the end of the job. A default
|
|---|
| 142 | region with a default production cut is automatically created and assigned
|
|---|
| 143 | to the world volume.</P>
|
|---|
| 144 |
|
|---|
| 145 | <hr><a href="../../../../Authors/html/subjectsToAuthors.html">
|
|---|
| 146 | <i>About the authors</a></i> </P>
|
|---|
| 147 |
|
|---|
| 148 | </body>
|
|---|
| 149 | </html>
|
|---|
