Notes

• Whenever possible GEANT makes use of the ZEBRA store for large data structures. This allows it to adapt the size of the program data portion to the size of the problem. The total amount of space required depends on the application. GEANT can run with as little as 50,000 words or less, but for large detectors it is not uncommon to declare stores of several million words. The call to GZEBRA initialises the common /GCBANK/ to receive the GEANT data structures. This call is necessary before any other routine of the GEANT system is called.
• The call to HLIMIT initialises the ZEBRA system to use the /PAWC/ common block for the HBOOK histogram package. The size of the common depends on the number and size of the plot requested. The ZEBRA system must be initialised only once, and the negative argument to HLIMIT prevents a second initialisation of the system. The HLIMIT call has to be placed after the call to GZEBRA and the argument has to be the dimension of the /PAWC/ common block with a negative sign in front.
• The main program is intended for batch applications, while to run the simulation interactively, the interactive main program called GXINT should be linked in front of the user code.
• The program shown will require the graphic libraries in the link sequence. Often, for batch production or for small tests, graphics is not needed, and not loading the graphics code makes the program smaller. To avoid loading graphic routines the calls to IGINIT, IGMETA, IGEND, GDINIT and GDEBUG should be removed.

  If, on the other hand, the user is interested in including the routine GDEBUG and in excluding graphics at the same time, then the following routine should be included in the code:

        SUBROUTINE GDCXYZ
        ENTRY IGSA
        ENTRY GDTRAK
        END
  

  which will avoid every reference to the graphics routines from GDEBUG.

• The user code to define the tracking media and the geometry of the setup should be inside the routine UGEOM. The pre-initialised data structured can be read from disk, but it is recommended to call GPHYSI in any case, to initialise the cross-section tables. An example of a full material, geometry and detector design is given below and has been extracted from the example GEXAM3. Here only major calls are shown, the redundant parts can be found in the source code of UGEOM in GEXAM3.

  The example shows the basic concept in GEANT. First material parameters are defining the properities of a detector material calling the subroutine GSMATE. Here in addition to the 16 predefined materials, the material definition of Calcium is examplary shown. More information towards the predefined materials and further use of material definition routines can be found in the section CONS001 - CONS101. Then tracking parameters are associated to the materials, defining a so called tracking medium. Each GEANT volume must be associated to an existing tracking medium. Here in the example the tracking medium 'TARGET' is defined to exist of Calcium.

  In the example shown below several detector volumes are defined using the subroutine GSVOLU. The defined volume have associated parameters of name, shape, tracking medium and shape parameters. In this example the volume 'TGT ' consists of the previously defined tracking medium 'TARGET'.The volumes (and if necessary identical copies of them) are then positioned according to the detector geometry. The volumes are positioned on the same level, or inside each other. By setting the parameter ONLY or MANY in the call of GSPOS the user has the opportunity to tell either GEANT the logical volume structure and to apply boolean operations (cutting, joining and intersection) between two positioned volumes. More information about the concept in defining volumes and positioning can be retrieved from the section GEOM.

  Finally the user is required to classify into sets all sensitive detectors (defined as those volume defined as detector via GSDET and other related routines, for which he wants to store hits in the hit data structure JHITS.

• It is convenient to store the input data records (see [BASE040]) in an auxiliary file ( gcards.dat in the example). This allows to have a standard input file and to overwrite selected input data records as needed. If, for instance, the standard gcards.dat file contains the record TRIG 1000 and a short test run is requested this can be obtained with the following input:

  READ 4
  TRIG 10
  STOP
  

  the first line instructs FFREAD to open and process the file connected with logical unit 4, and the second line (re-)defines the number of events to be processed. The STOP command ends the FFREAD processing of the input.
• In the above example the common blocks have not been expanded in the code. The notation used is the one of the PATCHY/ CMZ [,] code management systems. These products, among other things, can run as pre-processors, replacing the +SEQ,... instructions with the corresponding code fragments. Users are strongly recommended to use these systems to include GEANT common blocks in their code.

  Long experience in supporting GEANT users has shown that, as the user program grows, typing errors in the insertion of the common blocks by hand become very common, but difficult to find. The investment needed to learn a code management system at the user level is usually negligible compared with the time and energy needed in hunting a problem introduced by a mistyped common.

BASE110