Introduction to the Detector Response package

+-------------+                                               +----------##
| Geant 3.11  |               GEANT User's Guide              | HITS001  ##
+-------------+                                               +----------##
                                   

                                   

Author(s) : F.Bruyant                                  Submitted: 15.08.84
Origin    : GEANT3                                       Revised: 20.08.87

The detector response package

In the context of GEANT3:

  1. hit is the user defined 'information' recorded at tracking time to keep track of the interaction between one particle and a given detector, and regarded as necessary to compute the digitisations later.
  2. a digitisation is the user defined 'information' simulating the response of a given detector element, after tracking of a complete event.

The detector response package consists of tools to store in, and retrieve or print from, the data structures JSET, JHITS and JDIGI the information relevant to the hits and digitisations. A few subroutines which may help the user to solve some of the usual problems of digitisation in simple detectors have been added to the package, e.g. the intersection of a track with a plane or a cylinder and the digitisation of conventional drift and MWP chambers. For complex setups with different types of detectors the user has normally to define several types of hits and digitisations. In addition to the hits generated by all particles of the current event, computing the digitisations requires usually some information about the intrinsic characteristics and performance of the detectors. The information to be recorded for the hits and digitisations is highly experiment dependent, therefore only a framework can be proposed to store it. The solution adopted here should be satisfactory for most applications. Feedback from the users is needed and will be welcome.

Two remarks can be made:

  1. the stability of the information to be stored is usually reached much earlier for the hits than for the digitisations. Therefore the user may save computing time by designing an intermediate event output at the hits level.
  2. the scheme proposed for storing the digitisations should in any case be considered as an intermediate stage, a reshuffling of the data being necessary if the user wants to simulate more closely the specific format of the real data acquisition system.

SETs and DETectors

The reader is assumed to be familiar with the way the geometrical setup is described [GEOM 001], in particular with the concepts of logical volume structure and of physical path through the volume tree. The user is required to classify into sets all sensitive detectors for which storing the hits in the data structure JHITS is wanted. The 4-character names which identify the sets are user defined, and the list of sets which the user wants to activate for a given run can be entered through the data card SETS. The user is entirely free to group together, in one or in several sets, detectors of the same type or of different types. For convenience, it is recommended to have at least one set for each main component of the setup, e.g. hadron calorimeters, electromagnetic calorimeters, vertex chamber, etc. A volume can be declared as sensitive detector through the tracking medium parameter ISVOL, and allocated to a set through the subroutine GSDET or GSDETV. Each (logical) sensitive detector is identified by the 4 character name of the corresponding volume. As a given volume may describe several similar detectors of the physical setup, some additional information is needed for associating correctly the hits with the physical detectors. When making use of GSDET the user has to enter the (shortest) list of volume names, the vector NAMESV, which permits identification of the path through the physical tree, even in the presence of multiple copies at the volume level or at any lower level in the tree. The identification will be achieved when needed, by specifying a list of volume numbers, the vector NUMBV, in one to one correspondence with the above list of volume names. This list, after packing, will constitute the identifier of the physical detector. The routine GSDETV can be used instead of GSDET and then the system (through GGDETV called by GGCLOS) constructs the lists NAMESV automatically and stores them in the structure JSET.

The basic user tools

The data structure JSET is built through calls to the routine GSDET or GSDETV which assign detectors to sets and define their parameters, and to the auxiliary routines GSDETH, GSDETD and GSDETU which store respectively in the structure JSET, for each logical detector separately:

  1. the parameters required for the storage of the hit elements in the data structure JHITS, such as the packing and scaling conventions.
  2. the parameters required for the storage of the digitisations in the structure JDIGI, such as the packing conventions.
  3. the user parameters, which may consist, for instance, of the intrinsic detector characteristics needed for computing the digitisations.

To permit storage of more than one type of hit for a given sensitive detector, or to provide additional detector entries, detector 'aliases' can be defined through calls to the routine GSDETA. They are entered in the JSET structure as new detectors, with the same geometrical characteristics as the original one. Then, the user has the possibility to call appropriate routines GSDETH, GSDETD and GSDETU for this new detector. During the tracking, for each step inside the sensitive detectors, under control of the subroutine GUSTEP, the hits can be stored in the data structure JHITS with the subroutine GSAHIT (or GSCHIT, more appropriate for calorimetry). For each hit the information consists of:

  1. the reference to the track in the structure JKINE,
  2. the packed identifier of the physical detector, and
  3. the packed data for the different elements of the hit.

When the tracking has been completed for the whole event the digitisations can be computed in the user subroutine GUDIGI which may extract the hits with the subroutine GFHITS and store the digitisations in the data structure JDIGI, with the subroutine GSDIGI. For each digitisation the information should at least consist of:

  1. the reference to the track(s),
  2. the packed identifier of the physical detector, and
  3. the packed data for the digitisation itself.

Retrieval of geometrical information

The packed identifier of a physical detector, stored as part of the hit (or digitisation) information, is returned unpacked by the routines GFHITS (or GFDIGI) which extract the information from the JHITS or JDIGI structures, and may be used to retrieve the geometrical characteristics of the given detector. This is automated through the use of the routines GFPATH (which assumes that the sensitive detectors have been declared through the routine GSDETV, not GSDET) and GLVOLU which fills the common /GCVOLU/. GFPATH prepares the lists LNAM and LNUM required by the routine GLVOLU [GEOM 001], according to the information preprocessed at initialisation time by the routine GGDETV and stored in the structure JSET