Docstoc

A Hands-on introduction to Geant4

Document Sample
A Hands-on introduction to Geant4 Powered By Docstoc
					Wednesday, Nov. 10


   • 9:30-12:30
      – boolean solids
      – more on geometry - replicas
   • 14:00-17:00
      – parameterised volumes
      – EM field
Boolean solids
Solids from boolean operations
   • A very interesting feature of Geant4 is the possibility of
     combining simple solids with boolean operations




   • To create such a “new” boolean solid, one needs:
      – Two solids
      – a boolean operation (union, intersection, subtraction)
      – (optionally) a transformation for the second solid
   • The solids used should be either CSG solids or another
     boolean solid (result of a previous boolean operation)
Boolean solids


 #include “G4UnionSolid.hh”
 #include “G4SubtractionSolid.hh”
 #include “G4IntersectionSolid.hh”
 ….
 G4Box box1(“Box #1”,20,30,40);
 G4Tubs cylinder1(“Cylinder #1”,0,50,50,0,2*M_PI);

 G4UnionSolid b1UnionC1(“Box+Cylinder”,&box1,&cylinder1);
 G4IntersectionSolid b1IntersC1(“Box intersect Cylinder”,&box1,&cylinder1);
 G4SubtractionSolid b1MinusC1(“Box-Cylinder”,&box1,&cylinder1);
Boolean solids (2)
    • The more useful case is the one where one of the solids is
      displaced from the origin of the coordinates of the first
      (reference) solid
    • This can be done
       – Either by giving a rotation matrix and a translation vector that are
         used to transform the coordinate system of the first solid to the
         coordinate system of the second solid (passive method)
       – or by creating a transformation that moves the second solid from
         its desired position to its standard position
    • In the first case the translation is applied first to move the
      origin of coordinates. Then the rotation is used to rotate the
      coordinate system of the first solid to the coordinate
      system of the second solid
Boolean solids (3)
    G4RotationMatrix yRot45deg;
    yRot45deg.rotateY(M_PI/4);
    G4ThreeVector translation(0,0,50);

    G4UnionSolid boxUnionCyl1(“box union cylinder”,
                                &box1,&cylinder1,&yRot45deg,translation);

    // the same solid with the active method

    G4RotationMatrix InvRot=yRot45deg;
    InvRot.invert();

    G4Transform3D transform(InvRot,translation);
    G4UnionSolid boxUnionCyl2(“box union cylinder”,
                                 &box1,&cylinder1,transform)
boolean
  • The aim of the exercise is to implement the mother
    volumes for the three major subdetectors in Atlas (inner
    detector, calorimeters, muon) by using boolean solids.




  • Implement the inner detector as a normal tube, the
    calorimeter as a subtraction and the muon part as union
Geometry revisited
MaterialManager
 • One of the most unpleasant chores in GeantN is to define materials
 • The same material can be used in two (or more) different classes,
   hence, to avoid duplication of information, one must find a way of
   storing and retrieving materials into some “container”
 • MaterialManager is a naïve solution to this problem. By default, it
   has a table which contains predefined elements and materials
   (which can be completed, though) and a series of methods for
   storing new materials and retrieving the ones already stored
 • MaterialManager is a singleton, only one object of type
   MaterialManager can exist at any time. You can retrieve the
   pointer to it by simply calling the GetMaterialManager() method
    – MaterialManager *matManager=MaterialManager::GetMaterialManager();
MaterialManager (2)
• Other methods of the MaterialManager that you can use are:
   –   void storeElement(G4String name,G4String symbol,G4double z,G4double a)
   –   G4Element* getElement(G4String symbol);
   –   void storeMaterial(G4String name, G4double z,G4double a, G4double dens)
   –   void storeMaterial(G4String name, G4double density, G4int ncomponents)
   –   G4Material* getMaterial(G4String name)
   –   void addMaterial(G4String name1,G4String name2,G4double fraction)
   –   void addElement(G4String name1, G4String name2, G4double fraction)
   –   void addElement(G4String name1, G4String name2, G4int natoms)
   –   void printMaterialTable()
   –   void printElementTable()
Geometry, once again

   • The geometrical representation of the detector elements focuses
     on the solid models definition and their spatial position, as well
     as their logical relations, such as containment
   • Geant4 manages the representation of the detector element
     properties via the concept of Logical Volume
   • Geant4 manages the representation of the detector element
     spatial positioning and their logical relation via the concept of
     Physical Volume
   • Geant4 manages the representation of the detector element solid
     modeling via the concept of solid
   • The Geant4 solid modeler is STEP compliant. Step is the ISO
     standard for exchanging geometrical data between CAD systems
G4VSolid

 • G4VSolid is the base class for solids, physical shapes that can be
   tracked through
 • Costructors and destructor in G4VSolid automatically add/remove
   a solid to/from the solid store
 • G4VSolid defines but does not implement methods to compute
   distances to/from the shapes. Functions are also defined to check
   whether a point is inside the shape, to return the surface normal at
   a given point and to compute the extent of a shape
 • Protected/private utilities are implemented for the clipping of
   regions (to calculate the extent of a solid) and for visualization
   purposes
BREPs
 • BREPs are defined via the description of their boundaries. The
   boundaries can be made of planar and second order surfaces. The
   resulting solids are know as Elementary BREPs
 • Boundary surfaces can be made of Bezier surfaces and B-splines,
   or of NURBS (Non-Uniform Rational B-Splines) surfaces. These
   solids are Advanced BREPs
 • BREPs solids are defined by creating each surface separately and
   tying them together. Although it is possible to do this using code,
   it is much more convenient to use a CAD system
 • Models from a CAD system can be exported utilising the step
   standard, so BREP solids are normally defined via the use of a
   STEP reader.
 • Implemented in G4BREPSolid and derived classes
CSGs
 • Apart from those methods needed to create a shape, all CSGs
   implement a full set of methods for R/W access to the solids
   dimensions
 • G4Box
    void SetXHalfLength(G4double)    G4double GetXHalfLength()
    void SetYHalfLength(G4double)    G4double GetYHalfLength()
    void SetZHalfLength(G4double)    G4double GetZHalfLength()
 • G4Trd
    void SetX1HalfLength(G4double)   G4double GetX1HalfLength()
    void SetX2HalfLength(G4double)   G4double GetX2HalfLength()
    void SetY1HalfLength(G4double)   G4double GetY1HalfLength()
    void SetY2HalfLength(G4double)   G4double GetY2HalfLength()
    void SetZHalfLength(G4double)    G4double GetZHalfLength()
CSGs (2)

  • These functions are needed for modifying the solid after it has
    been created
     – Create a “big” Logical Volume, fill it up with lots of other volumes,
       recalculate its dimensions, squeeze it to its minimum permitted size
  • Careful! The modification of a solid after it has been assigned
    to the LV causes the LV, the PV etc… to be modified. Just
    make sure you have things under control
  • These “modifiers” are used typically in the calculations being
    made inside the Parameterisations, to modify the solids shape
    and dimensions (see later)
Logical Volumes (again)
   • The Logical Volume manages the information associated
     to detector elements represented by a given solid and
     material, independently from its physical position in the
     detector
   • A Logical Volume knows what are the physical volumes
     contained in it and is defined to be their mother volume
   • A Logical Volume can thus represent a full hierarchy of
     unpositioned volumes in the global reference frame (but
     with a defined position between themselves)
   • A Logical Volume also manages the information relative
     to Visualisation attributes and user-defined parameters
     related to tracking, fields or cuts
Logical Volume constructor

  G4LogicalVolume ( G4Vsolid* pSolid,
                    G4Material* pMaterial,
                    const G4String& name,
                    G4FieldManager* pFieldMgr=0,
                    G4VSensitiveDetector* pSDetector=0,
                    G4UserLimits* PULimits=0)


  Where

  pFieldManager   is a pointer to the field (electric or magnetic) implementation
  pSDetector      is a pointer to a Sensitive Detector (to make this volume
                  sensitive and collect the hits
  PULimits        is a set of user defined cuts (for the tracking into this volume)
Physical Volume types

   • Physical Volumes represent the spatial positioning of the
     volumes describing the detector elements
   • Several different techniques can be used:
      – Placement
         • involves the definition of the transformation for the volume to
            be positioned
      – Repeated positioning
         • defined by using the nr. ff times a volume should be replicated
            at a given distance along a given direction
      – Parameterised volumes
         • defined by describing a parameterised formula to specify the
            characteristics and positions of multiple copies of a volume
Single positioned copy
   • The physical volume is created by associating a Logical
     volume with a rotation matrix and a translation vector
   • The rotation matrix represents the rotation of the reference
     frame of the considered volume relatively to its mother’s
     reference frame
   • The translation vector represents the translation of the
     current volume in the reference frame of its mother volume
    G4PVPlacement ( G4RotationMatrix *pRot,             // Rotation Matrix
                    const G4ThreeVector &tlate,         // Translation Vector
                    const G4String &pName,              // Name
                    G4LogicalVolume *pLogical, // Logical Volume
                    G4VPhysicalVolume *pMother,          // Mother Vol. (physical!)
                    G4bool pMany,                       // Not used
                    G4int pCopyNo)                       // Copy Nr.
Single positioned copy (2)

   • A positioned volume keeps a pointer to the rotation matrix,
     not a copy of it! If the rotation matrix is re-used and
     modified, the physical volume will be affected!
   • Boolean operations at the level of Physical Volume
     (‘MANY’ in G3) are not implemented, so pMany must
     remain false. An alternative implementation of boolean
     operations exist for solids, which permits the union,
     intersection and subtraction of volumes
   • The mother volume must be specified for all volumes,
     except for the world volume
Single positioned copy (3)
   • An alternative way to specify a Placement utilises a
     different method to place a volume
   • The solid itself is rotated and translated in order to bring it
     into the system of coordinates of the mother volume
     (active method)
        G4PVPlacement (   G4Transform3D solidTransform,
                          const G4String &pName,
                          G4LogicalVolume *pLogical,
                          G4VPhysicalVolume *pMother,
                          G4bool pMany,
                          G4int pCopyNr);


   • Where:
        G4Transform3D (   G4RotationMatrix &pRot,
                          G4ThreeVector &tlate)
Single positioned copy (4)


   • An alternative method is to position the daughter volume
     into its mother’s Logical Volume
   • Please note the arguments order!

   G4PVPlacement ( G4RotationMatrix *pRot,             // Rotation Matrix
                   const G4ThreeVector &tlate,         // Translation Vector
                   G4LogicalVolume *pLogical, // Logical Volume
                   const G4String &pName,              // Name
                   G4LogicalVolume *pMother,           // Mother Vol. (logical!)
                   G4bool pMany,                       // Not used
                   G4int pCopyNo)                       // Copy Nr.
Repeated Volumes
  • In this case a single Physical Volume represent multiple
    copies of a volume within its mother volume, thus
    allowing to save memory.
  • This is normally done when the volumes to be positioned
    show a well defined rotational or translation symmetry
    along a cartesian or cylindrical coordinate
  • The Repeated Volume technique is only available for
    volumes described by CSG solids
     – Replica
        • Similar to G3 divisions
        • Very efficient for tracking but cumbersome and limiting
     – Parameterised Volume
        • Very, very powerful, but be careful...
Replicas
   • Replicas are Repeated Volumes in the case when the
     multiple copies of the volume to be positioned are all
     identical
   • The coordinate axis and the number of replicas need to be
     specified for the program to compute at run time the
     transformation matrix corresponding to each copy
      G4PVReplica (    const G4String &pName,
                       G4LogicalVolume *pLogical,
                       G4VPhysicalVolume *pMother,
                       const Eaxis pAxis,
                       const G4int nReplicas,
                       const G4double width,
                       const G4double offset=0)
   • Where:
       pAxis = kXAxis,kYAxis,kZAxis,kRho,kRadial3D,kPHi
replica

   • The aim of the exercise is to define a very simple lead
     scintillator calorimeter
      – the calorimeter is a box (already implemented)
      – its dimensions are given by the variable calo_xside and calo_yside
      – the thickness of the calorimeter is calculated out of the number of
        sandwiches one wants to position in, the thickness of the lead
        plates and the thickness of the scintillator plates
      – use the MaterialManager to get pointers to the materials needed
      – use a replica to position the lead-scintillator sandwiches
      – check, by shooting particles, that everything is correct
      – optionally, add physics (from ExN04) and the ExN02EventAction
        and try to generate a shower into the calorimeter
Parameterised Volumes

   • Parameterised Volumes are Repeated Volumes in the case
     in which the multiple copies of a volume can be different
     in size, solid type or material
   • The solid’s type, its dimensions, the material and the
     transformation matrix can all be parameterised in function
     of the copy number, either when a strong simmetry exist
     and when it does not
   • The user implements the desired parameterisation function
     and the program computes and updates automatically at
     run time the information associated to the Physical Volume
Parameterised Volumes (2)
   • For parameterised volumes one must always specify a
     mother volume, hence the World volume cannot be
     parameterised
   • The mother volume can be specified either as a Physical or
     Logical volume
    G4PVParameterised ( const G4String&               pName, // Name
                        G4LogicalVolume*              pLogical, // its logical volume
                        G4VPhysicalVolume* pMother,   // it can be G4LogicalVolume
                        const Eaxis                   pAxis,       // search axis
                        const G4int                   nReplicas, // nr. of replicate volumes
                        G4VPVParametrisation*         pParam); // the parameterisation

   • Note that the search axis is just a hint to Geant4 and not a
     direction along which the parameterisation must take place
An example of Parameterised Volume (N02)
// An example of Parameterised volumes
// dummy values for G4Box -- modified by parameterised volume
G4VSolid *solidChamber = new G4Box(“ChamberBox”,10*cm, 10*cm, 10*cm);
G4LogicalVolume *trackerChamberLV =
                                new G4LogicalVolume(solidChamber,Aluminium,”trackerChamberLV”);
G4VPVParameterisation *chamberParam= new ExN02ChamberParameterisation(
                                                    6,                // Nr. Of chambers
                                                    -240*cm,          // Z of the centre of the first
                                                    80*cm,            // Z spacing of the centres
                                                    20*cm,            // Width of the chambers
                                                    50*cm,            // lengthInitial
                                                    trackerSize/2.);  // lengthFinal
G4VPhysicalVolume *trackerChamber_phys = new G4PVParameterised (
                                         “tracker chamber PV”,        // name
                                         trackerChamberLV,            // Its logical volume
                                         physiTracker,                // Mother physical volume
                                         kZAxis,                      // placed along the Z axis
                                         6,                           // nr. Of chambers
                                         chamberParam);               // the parameterisation
The Parameterisation
   • The power of parameterised volumes is created by the
     parameterisation class and its methods
   • Geant4 parameterisations must derive from the
     G4VPVParameterisation class and implement (at least)
     two methods:
      – ComputeTransformation
         • Called with a copy number for the instance of the
           parameterisation under consideration. It must compute the
           transformation for this copy and set the physical volume to
           utilise this transformation
      – ComputeDimensions
         • Called with the copy number for the instance of the
           parameterisation. It must define the size of the solid for the
           volume being considered
An example of Parameterisation (N02)
class ExN02ChamberParameterisation: public G4VPVParameterisation {
…..
void ComputeTransformation   (const G4int                   copyNo,
                              G4VPhysicalVolume*            physVol) const;
void ComputeDimensions       (G4Box&                        trackerLayer,
                              const G4int                   copyNo,
                              const G4VPhysicalVolume*      physVol) const;
};
   • The ComputeTransformation() method set the
     transformation from a series of predefined parameters
void ExN02ChamberParameterisation::ComputeTransformation(const G4int copyNo,
                                                           G4VPhysicalVolume* physVol) const
{
         G4double Zposition = fStartZ + copyNo + fSpacing;
         G4ThreeVector origin(0,0,Zposition);
         physVol->SetTranslation(origin);
         G4RotationMatrix* identity=new G4RotationMatrix; // intentional memory leak!! Shoot me!!
         physVol->setRotation(identity);
}
An example of Parameterisation (N02)

    • Similarly the ComputeDimensions() method is used to set
      the size of that copy
Void ExN02ChamberParameterisation::ComputeDimensions( G4Box& trackerChamber,
                                                       const G4int copyNo,
                                                       const G4VPhysicalVolume* physVol) const
{
         G4double halfLength= fHalfLengthFirst + (copyNo-1) * fHalfLengthIncr;
         trackerChamber.SetXHalfLength(halfLength);
         trackerChamber.SetYHalfLength(halfLength);
         trackerChamber.SetZHalfLength(fHalfWidth);
}


    • Users must make sure that the type of the first argument
      (G4Box& here) corresponds to the type of the object given
      to the Logical Volume of parameterised physical volume
Parameterised Volumes (3)
 • Advanced usage of Parameterised Volumes permits also:
    – to change the type of solid by creating a ComputeSolid() method
    – to change the material of the volume by creating a ComputeMaterial() method
 • Very complex geometry descriptions can be achieved using a single
   (although complicated) parameterisation
    – who will be the first trying to describe the whole Atlas geometry with a single
      parameterisation?
 • The Compute… methods are executed at every step, hence:
    – make the algorithmic part as simple and as fast as possible
    – beware of memory leaks!!!!!
 • Currently, for many cases it is not possible to add daughter volumes
   to a parameterised volume (use them as “leaf” volumes)
parameterisation


   • The aim of the exercise is again to build a lead-scintillator
     calorimeter, this time though the calorimeter will be a
     trapezoid (wedge) and one must position scintillator plates
     into it made out of boxes
   • use the parameterisation which is already provided
     (ParameterisedScintillator.hh), figure out how many
     parameters do you need for doing the job, fill up the
     ComputeTransformation() and ComputeSolid()
Touchables
Touchables

 • Touchable Volumes provide a way of uniquely identifying a
   detector element in the geometrical hierarchy
    – for navigating in the geometry tree for storing hits
    – for providing a geometry description alternative to the one used by the
      Geant4 tracking system
    – for parameterised geometries
 • A touchable is a geometrical volume (solid) which has a unique
   placement in a detector description
 • In Geant4, touchables are implemented as solids associated to a
   transformation matrix in the global reference system or as a
   hierarchy of physical volumes
G4VTouchable
  • All G4VTouchable implementations must respond to at least
    two requests:
     – GetTranslation() and GetRotation() that return the components and the
       volume’s transformation
     – GetSolid() that gives the solid associated to the touchable
  • additional requests can be satisfied by touchables keeping a
    physical volume
     – GetVolume() which returns a physical volume
     – GetReplicaNumber() which returns the copy nr. (if set)
  • Touchables that store a complete stack of parent volumes, thus
    it is possible to add more functionality
     – GetHistoryDepth() to retrieve how many levels are there in the tree
     – MoveUpHistory(n) allows to navigate in the tree
Touchable History
 • A logical volume represents unpositioned detector elements,
   even a physical volume can represent multiple detector
   elements
 • Touchables provide a unique identification for a detector
   element
    – Transportation and tracking exploit the implementation of touchables
      implemented via the TouchableHistory
 • TouchableHistory is the minimal set of information required to
   build the full genealogy on top of a given physical volume up
   to the root of the geometrical tree
 • Touchables are made available to the user at every step during
   tracking by means of a G4Step object
Touchable History (2)
  • To create a G4TouchableHistory you must ask the
    navigator
     – G4TouchableHistory* CreateTouchableHistory() const;
  • to navigate in the geometrical tree you can use
     – G4int GetHistoryDepth() const;
     – G4int MoveUpHistory(G4int num_levels=1);
  • The first method tells you how many level deep in the
    current tree the volume is, the second asks the touchable to
    eliminate its deepest level
  • The MoveUpHistory significantly modifies the state of the
    touchable

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:7
posted:3/21/2012
language:
pages:38