| 1 | <html> |
|---|
| 2 | <head> |
|---|
| 3 | <title>ADG: Geometry</title> |
|---|
| 4 | </head> |
|---|
| 5 | |
|---|
| 6 | <!-- Changed by: Gabriele Cosmo, 18-Apr-2005 --> |
|---|
| 7 | <!-- $Id: geomDynamic.html,v 1.2 2006/06/09 14:00:48 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="geomOverlap.html"> |
|---|
| 17 | <IMG SRC="../../../../resources/html/IconsGIF/Previous.gif" ALT="Previous"></a> |
|---|
| 18 | <a href="geomXML.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.12"> |
|---|
| 34 | <h2>4.1.12 Dynamic Geometry Setups</h2></a> |
|---|
| 35 | |
|---|
| 36 | <p> |
|---|
| 37 | Geant4 can handle geometries which vary in time (e.g. a geometry varying |
|---|
| 38 | between two runs in the same job). |
|---|
| 39 | <br> |
|---|
| 40 | It is considered a change to the geometry setup, whenever: |
|---|
| 41 | <UL> |
|---|
| 42 | <LI>the shape or dimension of an existing solid is modified;</LI> |
|---|
| 43 | <LI>the positioning (translation or rotation) of a volume is changed;</LI> |
|---|
| 44 | <LI>a volume (or a set of volumes, tree) is removed/replaced or added.</LI> |
|---|
| 45 | </UL> |
|---|
| 46 | Whenever such a change happens, the geometry setup needs to be first "opened" |
|---|
| 47 | for the change to be applied and afterwards "closed" for the optimisation to |
|---|
| 48 | be reorganised. |
|---|
| 49 | <br> |
|---|
| 50 | In the general case, in order to notify the Geant4 system of the change in the |
|---|
| 51 | geometry setup, the <TT>G4RunManager</TT> has to be messaged once the new |
|---|
| 52 | geometry setup has been finalised: |
|---|
| 53 | |
|---|
| 54 | <PRE> |
|---|
| 55 | G4RunManager::GeometryHasBeenModified(); |
|---|
| 56 | </PRE> |
|---|
| 57 | |
|---|
| 58 | The above notification needs to be performed also if a material associated to |
|---|
| 59 | a <i>positioned</i> volume is changed, in order to allow for the internal |
|---|
| 60 | materials/cuts table to be updated. |
|---|
| 61 | |
|---|
| 62 | However, for relatively complex geometries the re-optimisation step may be |
|---|
| 63 | extremely inefficient, since it has the effect that the whole geometry setup |
|---|
| 64 | will be re-optimised and re-initialised. In cases where only a limited |
|---|
| 65 | portion of the geometry has changed, it may be suitable to apply the |
|---|
| 66 | re-optimisation only to the affected portion of the geometry (subtree). |
|---|
| 67 | <br> |
|---|
| 68 | Since release 7.1 of the Geant4 toolkit, it is possible to apply |
|---|
| 69 | re-optimisation local to the subtree of the geometry which has changed. The |
|---|
| 70 | user will have to explicitly "open/close" the geometry providing a pointer |
|---|
| 71 | to the top physical volume concerned: |
|---|
| 72 | </p> |
|---|
| 73 | |
|---|
| 74 | <p> |
|---|
| 75 | <center> |
|---|
| 76 | <table BORDER=1 CELLPADDING=8> |
|---|
| 77 | <TR><TD> |
|---|
| 78 | <pre> |
|---|
| 79 | #include "G4GeometryManager.hh" |
|---|
| 80 | |
|---|
| 81 | // Open geometry for the physical volume to be modified ... |
|---|
| 82 | // |
|---|
| 83 | G4GeometryManager::OpenGeometry(physCalor); |
|---|
| 84 | |
|---|
| 85 | // Modify dimension of the solid ... |
|---|
| 86 | // |
|---|
| 87 | physCalor->GetLogicalVolume()->GetSolid()->SetXHalfLength(12.5*cm); |
|---|
| 88 | |
|---|
| 89 | // Close geometry for the portion modified ... |
|---|
| 90 | // |
|---|
| 91 | G4GeometryManager::CloseGeometry(physCalor); |
|---|
| 92 | </pre> |
|---|
| 93 | <TR> |
|---|
| 94 | <TD ALIGN=center> |
|---|
| 95 | Source listing 4.1.9<BR> |
|---|
| 96 | Opening and closing a portion of the geometry without notifying the |
|---|
| 97 | <TT>G4RunManager</TT>. |
|---|
| 98 | </table> |
|---|
| 99 | </center> |
|---|
| 100 | </p> |
|---|
| 101 | |
|---|
| 102 | <p> |
|---|
| 103 | If the existing geometry setup is modified locally in more than one place, it |
|---|
| 104 | may be convenient to apply such a technique only once, by specifying a |
|---|
| 105 | physical volume on top of the hierarchy (subtree) containing all changed |
|---|
| 106 | portions of the setup. |
|---|
| 107 | </p> |
|---|
| 108 | |
|---|
| 109 | <p> |
|---|
| 110 | An alternative solution for dealing with dynamic geometries is to specify NOT |
|---|
| 111 | to apply optimisation for the subtree affected by the change and apply the |
|---|
| 112 | general solution of invoking the <TT>G4RunManager</TT>. In this case, a |
|---|
| 113 | performance penalty at run-time may be observed (depending on the complexity |
|---|
| 114 | of the not-optimised subtree), considering that, without optimisation, |
|---|
| 115 | intersections to all volumes in the subtree will be explicitely computed each |
|---|
| 116 | time. |
|---|
| 117 | </p> |
|---|
| 118 | |
|---|
| 119 | <hr><a href="../../../../Authors/html/subjectsToAuthors.html"> |
|---|
| 120 | <i>About the authors</a></i> </P> |
|---|
| 121 | |
|---|
| 122 | </body> |
|---|
| 123 | </html> |
|---|
