Cut per region Marc Verderi GEANT4 collaboration meeting 01/ 10/ - - PowerPoint PPT Presentation

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

• f a neighbouring volume with low cuts;

But requests from ATLAS, BABAR, CMS,

LHCb, …, to allow several cuts;

Globally or per particle;

Layout

I.

Generalities

II.

Analysis

III.

Design

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

• f 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

• f 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

• f the existing GEANT4;

About the status:

See Makoto’s presentation on Thursday