Bugfix in AliPoints2Memory
[u/mrichter/AliRoot.git] / GEANT321 / ghits / ghits.doc
1 *
2 * $Id$
3 *
4 * $Log$
5 * Revision 1.1.1.1  1995/10/24 10:21:08  cernlib
6 * Geant
7 *
8 *
9 #include "geant321/pilot.h"
10 #if defined(CERNLIB_DOC)
11 *CMZ :  3.21/02 29/03/94  15.41.20  by  S.Giani
12 *-- Author :
13 *
14 ************************************************************************
15 *                                                                      *
16 *           Introduction to the Detector Response package              *
17 *           ---------------------------------------------              *
18 *                                                                      *
19 *                                                                      *
20 * THE DETECTOR RESPONSE PACKAGE                                        *
21 *                                                                      *
22 * In the context of GEANT3:                                            *
23 *                                                                      *
24 * - a hit is  the user defined 'quantum of  information' recorded at   *
25 *   tracking  time to  keep  track of  the  interaction between  one   *
26 *   particle  and  a  given  sensitive  detector,  and  regarded  as   *
27 *   necessary to compute the digitisations later.                      *
28 *                                                                      *
29 * - a  digitisation is  the  user defined  'quantum of  information'   *
30 *   simulating  the  response of  a  given  detector element,  after   *
31 *   tracking  of a  complete event.                                    *
32 *                                                                      *
33 *  The detector response package consists  of tools to store in, and   *
34 * retrieve or print from, the  data structures JSET, JHITS and JDIGI   *
35 * the information  relevant to  the hits  and digitisations.   A few   *
36 * subroutines which  may help the  user to  solve some of  the usual   *
37 * problems of  digitisation in simple  detectors have been  added to   *
38 * the package,  e.g. the intersection of  a track with a  plane or a   *
39 * cylinder  and  the  digitisation  of conventional  drift  and  MWP   *
40 * chambers.                                                            *
41 *  For complex  set-ups with different  types of detectors  the user   *
42 * has normally  to define several  types of hits  and digitisations.   *
43 * In addition to the hits generated  by all particles of the current   *
44 * event,   computing  the   digitisations   requires  usually   some   *
45 * information about the intrinsic characteristics and performance of   *
46 * the detectors.                                                       *
47 *  The information to be recorded  for the hits and digitisations is   *
48 * highly  experiment dependent,  therefore only  a framework  can be   *
49 * proposed  to  store  it.   The solution  adopted  here  should  be   *
50 * satisfactory  for most  of  the applications.   Feedback from  the   *
51 * users is needed and will be welcome.                                 *
52 *  Two remarks can be made:                                            *
53 *                                                                      *
54 * - the stability of the information to be stored is usually reached   *
55 *   much earlier for the hits than for the digitisations.  Therefore   *
56 *   the user  may save computing  time by designing  an intermediate   *
57 *   event output at the hits level.                                    *
58 * - the scheme proposed for storing  the digitisations should in any   *
59 *   case be considered  as an intermediate stage,   a reshuffling of   *
60 *   the data  being necessary  if the  user wants  to simulate  more   *
61 *   closely the specific format of the real data acquisition system.   *
62 *                                                                      *
63 * SETS AND DETECTORS                                                   *
64 *                                                                      *
65 * The reader is assumed to be  familiar with the way the geometrical   *
66 * setup is described [GEOM 001],  in particular with the concepts of   *
67 * logical volume structure  and of physical path  through the volume   *
68 * tree.                                                                *
69 *  The  user  is  required  to  classify  into  sets  all  sensitive   *
70 * detectors for which  storing the hits in the  data structure JHITS   *
71 * is wanted.                                                           *
72 *  The 4-character names  which identify the sets  are user defined,   *
73 * and the list of sets which the  user wants to activate for a given   *
74 * run  can be  entered  through the  data card  SETS.   The user  is   *
75 * entirely  free to  group  together,  in one  or  in several  sets,   *
76 * detectors  of   the  same  type   or  of  different   types.   For   *
77 * convenience, it is  recommended to have at least one  set for each   *
78 * main   component  of   the   setup,   e.g.  hadron   calorimeters,   *
79 * electromagnetic calorimeters, vertex chamber, etc.                   *
80 *   A detector  can be  declared as  sensitive through  the tracking   *
81 * medium  parameter  ISVOL,  and  allocated to  a  set  through  the   *
82 * subroutine GSDET.   Currently, the active sets  and detectors have   *
83 * to be  redefined for every run.   Tools will be provided  later to   *
84 * read in part  or the whole of the information  from a previous run   *
85 * and  to  update the  relevant  structures  according to  the  user   *
86 * requirements.                                                        *
87 *   Each (logical) detector is identified by the 4-character name of   *
88 * the corresponding volume.  As a  given volume may describe several   *
89 * similar  detectors   of  the   physical  setup,   some  additional   *
90 * information is needed for associating  correctly the hits with the   *
91 * physical detectors.  The user has  to enter the (shortest) list of   *
92 * volume names,  the vector NAMESV, which  permits identification of   *
93 * the  path through  the  physical  tree, even  in  the presence  of   *
94 * multiple copies at  the volume level or at any  lower level in the   *
95 * tree.   The  identification  will  be  achieved  when  needed,  by   *
96 * specifying a list  of volume numbers, the vector NUMBV,  in one to   *
97 * one  correspondence with  the above  list of  volume names.   This   *
98 * list,  after  packing,  will  constitute  the  identifier  of  the   *
99 * physical detector.                                                   *
100 *                                                                      *
101 * THE BASIC USER TOOLS                                                 *
102 *                                                                      *
103 * The  data structure  JSET is  built through  calls to  the routine   *
104 * GSDET  which  allocates  detectors   to  sets  and  defines  their   *
105 * parameters,  and  to the  auxiliary  routines  GSDETH, GSDETD  and   *
106 * GSDETU which  store respectively in  the structure JSET,  for each   *
107 * logical detector separately:                                         *
108 *                                                                      *
109 * - the parameters required  for the storage of the  hit elements in   *
110 *   the  data  structure JHITS,  such  as  the packing  and  scaling   *
111 *   conventions.                                                       *
112 *                                                                      *
113 * - the parameters required for the  storage of the digitisations in   *
114 *   the structure JDIGI,  such as the packing  conventions. the user   *
115 *   parameters, which  may consist,  for instance, of  the intrinsic   *
116 *   detector characteristics needed for computing the digitisations.   *
117 *                                                                      *
118 *  To  permit storage  of more  than  one type  of hit  for a  given   *
119 * sensitive  detector, detector  'aliases'  can  be defined  through   *
120 * calls  to  the routine  GSDETA.   They  are  entered in  the  JSET   *
121 * structure  as  additional  detectors, with  the  same  geometrical   *
122 * characteristics  as the  original  one.  Then,  the  user has  the   *
123 * possibility to  call the  appropriate routines GSDETH,  GSDETD and   *
124 * GSDETU.                                                              *
125 *  During  the   tracking,  for  each  step   inside  the  sensitive   *
126 * detectors, under control of the subroutine GUSTEP, the hits can be   *
127 * stored in the data structure  JHITS with the subroutine GSAHIT (or   *
128 * GSCHIT,  more  appropriate for  calorimetry).   For  each hit  the   *
129 * information consists of:                                             *
130 *                                                                      *
131 * - the reference to the track in the structure JKINE,                 *
132 * - the packed identifier of the physical detector, and                *
133 * - the packed data for the different elements of the hit.             *
134 *                                                                      *
135 *  When  the tracking  has been  completed for  the whole  event the   *
136 * digitisations can be computed in  the user subroutine GUDIGI which   *
137 * may  extract the  hits with  the subroutine  GFHITS and  store the   *
138 * digitisations  in the  data structure  JDIGI, with  the subroutine   *
139 * GSDIGI.   For each  digitisation the  information should  at least   *
140 * consist of:                                                          *
141 *                                                                      *
142 * - the reference to the track(s),                                     *
143 * - the packed identifier of the physical detector, and                *
144 * - the packed data for the digitisation itself.                       *
145 *                                                                      *
146 * RETRIEVAL OF GEOMETRICAL INFORMATION                                 *
147 *                                                                      *
148 *  The packed  identifier of as  physical detector stored a  part of   *
149 * the hit  (or digitisation) information, is  returned (unpacked) by   *
150 * the routines GFHITS  or GFDIGI which extract  the information from   *
151 * the JHITS  or JDIGI structures,  and may  be used to  retrieve the   *
152 * identity and geometrical characteristics of the given detector.      *
153 *   At  the  moment this  is  automatized  through  the use  of  the   *
154 * routines GFPATH  (which assumes that the  sensitive detectors have   *
155 * been declared  through the routine  GSDETV, not GSDET)  and GLVOLU   *
156 * which fills the common /GCVOLU/.                                     *
157 *   GFPATH prepares the lists LNAM  and LNUM required by the routine   *
158 * GLVOLU [GEOM 001].                                                   *
159 *   Worth  is in  progress in  this area  and might  lead to  a more   *
160 * transparent approach.  Therefore, the  routines GSDETV, GGDETV and   *
161 * GFPATH  and  their action  on  the  structure  JSETS will  not  be   *
162 * documented in more detail now.                                       *
163 *                                                                      *
164 ************************************************************************
165 #endif