Cut per region Marc Verderi GEANT4 collaboration meeting 01/ 10/ 2002
Introduction � Cut here = « production threshold »; � Not tracking cut; � GEANT4 originally designed to allow a unique cut in range; � Unique cut in range per particle; � Default being a same cut for all particles; � Consistency of the physics simulated: � Garanties that a volume with high cuts (ie poor physics quality) will not « pollute » the simulation of a neighbouring volume with low cuts; � But requests from ATLAS, B A B AR , CMS, LHCb, …, to allow several cuts; � Globally or per particle;
Layout Generalities I. Analysis II. Design III.
I. Generalities
Cuts for what ? � Some physics processes involve infra-red divergences; � Bremsstrahlung; � Infinity of lower and lower energy photons; � Ionisation; � Huge number of low energy electrons; � Limited by the (low) ionisation potential; � Goal of cuts is to limit the discrete production of secondaries; � Corresponding energy is transfered to the continuous component;
Today’s picture � On the user side: � User constructs a detector: � Volumes � Materials � (S)he defines the physics processes to be used; � And then sets the cut; � Cut in range for the all simulation; � Eventually the cut may depend on the particle type; � On the G4 kernel side: � For each particle, G4 triggers the conversion of the cut in range into the equivalent energy threshold; � For each material; � Processes can then use these thresholds to compute their cross-section tables; � One table per material;
II. Analysis
Motivation for several cuts � Having a unique cut can be the source of performance penalties; � Part of the detector with lower cut needs fixes the cut for the all simulation; � Can be far too low than necessary in other parts; � Silicon vertex detector: a few 10 µ m; � Hadronic calorimeter: 1 cm; � Other parts being geometrically far, to.
Relaxing the unicity of cuts � Request to allow several cuts has been analyzed as follows: � A cut value is typically required at the level of a detector sub-system: � Silicon vertex detector: a few 10 µ m; � Hadronic calorimeter: 1 cm; � Introduce the concept of « region »: � Large geometrical area,typically the root logical volume of a sub-system; � Or an group of root logical volumes; � Eg: barrel + end-caps of the calorimeter; � A cut in range is associated to a region; � Eventually a range cut per particle is allowed;
III. Design
The region and cut classes, from the user point of view � The concept of region is realized by a new class, G4Region : � The user can set one or several root logical volumes to a region with method: � void AddRootLogicalVolume(G4LogicalVolume * ); � Cuts are implemented as a new class to, G4ProductionCut ; � Allows to defines a « default cut »; � Allows to specify eventually cuts for e - , e + , γ . � The user sets a G4ProductionCut pointer to each region (s)he defined;
The machinery, from the G4 kernel point of view (1) � Geometry: � Class G4Region implemented for the purpose of cuts, but could be of more general usage; � Could carry the magnetic field for example; � For performance reasons at tracking time, the region pointer is propagated recursively in the daughter volumes from the root logical volume; � Processes can interrogate directly the current volume at tracking time; � Same mechanism as in parameterisation; � Above mechanism requires a partition of the logical volumes; � A same logical volume can not belong to two different regions; � Understood as being a (very) weak limitation in practice;
Geometry
The machinery, from the G4 kernel point of view (2) � Processes: � Only regards processes dealing with cuts; � Main issue is to know which cross-section table to use in the current volume at tracking time; � In the current scheme, for a given process, there was a one-to-one relation between a material and a cross-section table: � This was used to retrieve the physics table using: � « index of material » == « index of physics table » � Now, since a same material may appear in several regions above relation is replaced by: � « index of {material, region} couple » == « index of physics table » � G4MaterialRegionCouple introduced for this management purpose;
Processes
The machinery (3) � Initialisation time: � Unreadable � scenario diagrams exist; � Basic scheme is: � Geometry and cut set up: � The user builds the geometry, sets up the regions, assigns cuts to the regions; � When the run manager closes the geometry: � It triggers a loop on the regions, builds, if needed, and set to the logical volumes the proper G4MaterialRegionCouple pointers; � The couple is updated with the energies from range conversion; � Then, the run manager triggers a loop on the physics processes, which can find in the material-cut table all informations to build the needed cross-section tables. � A scheme for reinitialisation after changes in the geometry was also made;
The machinery, from the G4 kernel point of view (4) � Tracking time: � Basic scheme is: � At a given point, the process asks the G4Track for the current material-cut couple; � It gets the related index; � And attacks the related cross-section table; � Case of parametrised volume anticipated also: � Less unreadable scenario diagram after…
Tracking time
Anticipated limitations � Partition of logical volumes; � Told about before; � G4ProductionCut defines a set of cuts for all particles; � But it can be that the same cut value appears for, say electrons, in two different cut objects; � And that same materials appear in the related regions; � In this case cross-section table will be calculated twice; � Looked quite a complication to take into account this case; � Might not be hopeless
Conclusion � Detailed design for cut per region has been made; � It does not imply severe design revision of the existing GEANT4; � About the status: � See Makoto’s presentation on Thursday
Recommend
More recommend
