Cut per region

1. Cut per region Marc Verderi GEANT4 collaboration meeting 01/10/2002

2. 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, BABAR, CMS, LHCb, …, to allow several cuts; • Globally or per particle;

3. Layout • Generalities • Analysis • Design

4. Generalities

5. 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;

6. 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;

7. Analysis

8. 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 mm; • Hadronic calorimeter: 1 cm; • Other parts being geometrically far, to.

9. 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 mm; • 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;

10. Design

11. 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+, g. • The user sets a G4ProductionCut pointer to each region (s)he defined;

12. 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;

13. Geometry

14. 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;

15. Processes

16. 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;

17. 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…

18. Tracking time

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

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