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