# Presentation: 128329

## 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)
- Where:

- G4PVPlacement (	G4Transform3D solidTransform,
- 		const G4String &pName,
- 		G4LogicalVolume *pLogical,
- 		G4VPhysicalVolume *pMother,
- 		G4bool pMany,
- 		G4int pCopyNr);

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

- G4PVReplica (	const G4String &pName,
- 		G4LogicalVolume *pLogical,
- 		G4VPhysicalVolume *pMother,
- 		const Eaxis pAxis,
- 		const G4int nReplicas,
- 		const G4double width,
- 		const G4double offset=0)

- 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
- Note that the search axis is just a hint to Geant4 and not a direction along which the parameterisation must take place

- 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

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

- The ComputeTransformation() method set the transformation from a series of predefined parameters

- class ExN02ChamberParameterisation: public G4VPVParameterisation {
- .....
- void ComputeTransformation 	(const G4int		copyNo,
- 			 G4VPhysicalVolume*	physVol) const;
- void ComputeDimensions	(G4Box&			trackerLayer,
- 			 const G4int		copyNo,
- 			 const G4VPhysicalVolume*	physVol) const;
- };
- 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
- 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

- 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);
- }

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