SICb User's Guide

next up previous

GEANT3-based simulation package for the LHCb experiment

June 19, 1997

cm Contact person: Tsaregorodtsev Andrei
e-mail: atsareg@afsmail.cern.ch

Contents

Getting started

CERN public facilities

To get started with using the program on RSPLUS/HPPLUS services one should make the following steps:

1.
Get an AFS user account in LHCb (z5) computing group. This will ensure that you will get the LHCb working environment defined upon logging in to any CERN public service (RSPLUS/HPPLUS/DXPLUS). If you are not a member of the z5 computing group, you will have to set up the environment variables by running the LHCb group profile:

for (t)csh shell:

  source /afs/cern.ch/lhcb/scripts/lhcbenv.csh

for (z)sh shell:

  . /afs/cern.ch/lhcb/scripts/lhcbenv.sh
2.
Choose or create a directory in which you will work on your code and which will receive the code from the CVS repository. Define MYROOT environment variable pointing to this directory. For example:
  mkdir $HOME/cvs
  setenv MYROOT $HOME/cvs
3.
Go to $MYROOT directory. Check out files in task package of the CVS repository to your $MYROOT directory. This is done by the following cvs command:
  cvs checkout task

This will create a task directory and will copy the following files to there:

Makefile
- file containing instructions to gmake command (see below) on how to compile your program;
sicb.dat
- an example of data cards to be used with the program;
sicb.job
- an example of a job script to be submitted to the batch queue system;
task1
- a directory containing an example of user routines.
4.
A suggested way to write and compile your analysis code is to put all the SUxxxx subroutines plus any other private subroutines in one directory, e.g. task1 directory. Then you execute gmake command which assumes that there is a Makefile in the current directory. The gmake command takes some arguments. One possible argument is the directory name which contains user code. For example, to compile and link the program with user routines in $MYROOT/task/task1 directory and Makefile in $MYROOT/task directory, it is necessary to change directory to $MYROOT/task and then type:
  gmake USDIR=task1

To compile the interactive version of the program:

  gmake USDIR=task1 MODE=int

This will prepare an executable file with a name sicb107.exe or sicbint107.exe respectively assuming that the current production version is 107.

5.
To run the program you will need a sicb.dat file containing necessary data cards. An example of the cards file you can find in the task directory checked out from the CVS repository as described above. These data cards should be in the current directory when running the program interactively. For the batch mode execution the data cards can be read in from the standard input stream (see example sicb.job ).

Now you can run an interactive version of the program. To submit a batch job you should get acquainted with llsubmit command provided for this purpose on CERNSP or NQS system which you can use to submit jobs to CSF facility.

Program overview

  
Figure 1: The general SICB program flow.

Detector description

In order to introduce a new detector, it is necessary to undertake several steps. Before the detector description is coded in the program it is necessary to get a number of parameters characterizing the detector. Those may be geometry and material, digitization, reconstruction and other parameters. All these parameters should be made available in the program by means of Constant Definition File (CDF). The format of such a file for different types of parameters is described in this section.

The CDF contains one or more blocks of the following format:

Keyword
  ....
  parameters
  ....
END Keyword

, where the Keyword represents different types of parameters. It is important to note that the parameters described in this way should be properly commented in the CDF. The comment lines are introduced by '#' sign in the first position. Also, all the line contents after the '!' sign is considered to be comments.

Materials and tracking media parameters

See D.

Rotation matrices

See E.

Detector parameters

UTDGET utility

The UTDGET subroutine is used to retrieve detector parameters from *.cdf files or from a special record stored along with generated data on tape. The parameters stored together with the data are extracted preferentially by default. The subroutine has the following calling sequence:

UTDGET(CHDETE,CHOPT,*NPAR*,ARRAY*)

 CHDETE detector name;

CHOPT options string:

'G'
-- geometry description parameters (default);
'C'
-- calculated geometry (not in *.cdf);
'H'
-- hit description parameters;
'D'
-- digitization parameters;
'R'
-- reconstruction parameters;
'F'
-- floating point parameters (default);
'I'
-- integer parameters;
'N'
-- take parameters from the *.cdf file;
'L'
-- ZEBRA pointer to the beginning of the parameters storage is returned in ARRAY(1).
 
NPAR  (I) 		 Input: 		 maximum number of parameters to be returned;

Output: actual number of parameters returned;

ARRAY array of parameters. ARRAY contain either REAL or INTEGER parameters depending on the options. It should be declared accordingly in the calling routine.

Control of the program behaviour

Managing Input/Output

Data stream definition

All the sources of any kind of data are assigned a unique 4-character identifier which is refered to further as a data stream. The assignment is done through the IOPA data card which has the following format:

IOPA
    'stream1' 'opt1' 'filename1!'
    'stream2' 'opt2' 'filename2!'
    ...
    'streamN' 'optN' 'filenameN!'

where 'stream' is a 4-character identifier, 'opt' -- options string ( see below ), filename -- full file pathname. The file name can contain environment variables and should be followed by the exclamation mark. Each file to be used in the program should be described in this manner.

In the program the following utilities are used to handle the files:

     CALL UTOPEN(CHSTREAM,LUNIT*)

Opens stream CHSTREAM (CH*4) on the unit LUNIT. LUNIT is the output parameter which can be used later, e.g. in WRITE/READ statements. The stream is opened according to the options specified in the IOPA card. If the stream is already opened, this call will just return the assigned logical unit number. The streams specified in IOPA data card are opened automatically. So, call to UTOPEN is necessary only if the user wants to check that the stream was successfully opened ( otherwise LUNIT=0 ) or if the stream was closed by

     CALL UTCLOSE(CHSTREAM)

This call closes the stream CHSTREAM according to the options specified in the IOPA card.

The following options are recognized:

'X'
- FZ eXchange format file;
'R'
- RZ file;
'H'
- HBOOK file ( see below );
'A'
- ASCII formatted file;
'U'
- Unformatted (FORTRAN) file;
'G'
- GEANT setup definition file;
'D'
- Data Definition File (see SICB data model section);
'C'
- Constant Definition File (see Detector Description section);
'L'
- List of files in the same format as IOPA data card;
'O'
- output file (default is an input readonly file)

The number of options may increase later for other file formats as well as for special files which will require some special action upon opening or closing.

There is a special stream 'STDT' which has a default definition in the program. Its definition may be still overridden by the IOPA card. This file contains some standard streams definitions in the same format as the IOPA card. This allows to hide standard files at standard locations necessary to the program but of no interest for the user.

One of the special stream options is 'HO'. This will open an HBOOK RZ file and made a subdirectory under //PAWC with the same name as that of the stream where the user is supposed to store his histograms. It is necessary to avoid histogram numbers clashing. On the output all the histograms in the subdirectory will be written to the stream.

Standard stream definitions

There are some standard streams that if defined alter the program behaviour.

 Stream    Option GETG 		  'G' 		 
                 the stream defines where the program will 
                 take the  setup GEANT description. If it is defined then
                 the setup definition will be skipped in the program;

SAVG 'GO' the output stream for the GEANT setup description structures;

GETE 'R' this stream defines the source to get event generator data. If it is not specified than the built-in PYTHIA generator will be used;

GETX 'X' this stream defines the source of the simulated data to be analyzed in the job. If it is defined the GEANT particle tracking will be skipped;

GETY 'X' this stream defines the source of the "underlying" events - those that together with the input in 'GETX' stream form the complete events. If both 'GETX' and 'GETY' streams are specified then the events from both will be merged together for the analysis; checking that two parts of the event are coming from the same generator event will be done. If only 'GETY' stream is specified then the event from this stream will be merged with the event fully processed in the job;

GETP 'X' this stream defines the source of the simulated data to be merged to event in GETX as if a pile-up event;

SAVX 'XO' this is an output stream for events processed in the job.

Event filter

PYTHIA/JETSET mode

To allow flexible choice of PYTHIA/JETSET mode of event generating the following data cards are provided:

 Data card Len Type MSEL 		 1 		 I 		 corresponds to PYTHIA MSEL parameter;

MSUB 50 I list of subprocesses to be switched on if MSEL=0. Subsequent pairs give process numbers and corresponding flag;

MSTB 10 I Codes of particles ( JETSET convention ) to be set stable in JETSET. Note that both particle and and corresponding antiparticle will be turned stable by means of MSTB data card;

MDEC 10 I Codes of particles ( JETSET convention ) to be forced to decay in JETSET. This card is used to override undesired setting in MSTB data card;

Particle selecting for tracking in GEANT

The cards described in this section are provided to select a particle of interest from PYTHIA output and to book a decay mode of particles overriding a default one. If no particular decay mode is specified for a particle then the particle will decay (if it is supposed to) according to the PYTHIA decay tables.

 Data card Len Type MBRT 		50 		 I 		  
                    defines a unique decay mode of a particle
during GEANT event processing. Subsequent pairs of numbers give 
particle code ( GEANT
convention ) and decay mode in the form:

,

where is a code of decay product number n. If is 00 for some product it corresponds to X. One can use also a generic code for leptons (see particle codes table). For example,

MBRT 73 9700

forces to decay semileptonically.

MSLT 100 MIX defines particles to be taken from PYTHIA output to GEANT tracking. The following options are provided:

'ALL ' all particles are selected for tracking independantly from settings in MKIN card;

'ALLK' all particles that satisfy settings in MKIN card are selected;

'NONE' no particles are selected for tracking. This option may be useful if one wants only to generate events in PYTHIA and store them on file;

'TAG ' ¯n tagging particles of flavour ; if n > 0 - these are direct B-hadron decay products; if n < 0 - these particles have a B-hadron somewhere on their decay history path (cascade);

'TAKE' selects n particles of flavour ;

'DROP' drops n particles of flavour . Some special codes may be used in this option:

1003
-- all the STRANGE descendants;
1004
-- all the CHARM descendants;
1005
-- all the BEAUTY descendants;
If n < 0 then the whole event will be dropped if at least
              one particle listed in this option will be encounted. This
              option is used in conjunction with either 'ALL ' or 'ALLK' 
              options and needs 'AND ' option to be also given;

MM MMMMM ¯ 'AND ' if this option is specified the particles selected will be taken with AND logic. If this option is given together with 'ALL ' or 'ALLK' option the event will be accepted only if other than 'ALL '/'ALLK' options are satisfied;

'USER' all the options are ignored and the event selection is done in the user supplied subroutine SUSELEV;

'TEST' ifl generates a test particle of flavour ifl in given kinematics ranges (MKIN card).

Data card Len Type ¯

MKIN 12 MIX kinematical limits for particles to be accepted for tracking:

MM MMMMM ¯ 'PMIN' minimum momentum;

'PMAX' maximum momentum;

'THMN' minimum theta;

'THMX' maximum theta;

'PHMN' minimum phi;

'PHMX' maximum phi;

Let us consider an example selection. Suppose, we need to generate an event with -meson within 600 mrad cone. We require also that it decays to and which in turn decay to muons and charged pions respectively. Let us also require that there should be a tagging lepton in the event. If both and tagging lepton are present then take all the particles in the evnet. These conditions lead to the following data cards:

c
c  PYTHIA mode
c
MSEL  5
c
c  make Bd0 stable
c
MSTB  511
c
c  force Bd0-bar to decay
c
MDEC -511
c
c  Decay mode for Bd0 (GEANT code 73)
c
MBRT  73  6416
      64  506
      16  809 
c
c  Select event
c
MSLT   'TAKE' 1 73
       'AND '
       'TAG ' 4 2 3 5 6
       'ALL '
MKIN   'THMN' 0.0
       'THMX' 0.6

Note that in this case only s from the will decay to muons. Other s will decay according to the PYTHIA tables. The same applies to the .

Version and description level control

There is a number of data cards used to choose the level of the detector parts description as well as the amount of debugging information to be printed out. These are cards: GEOM, SETS, HITS, DIGI, RECO, DEBG, PRNT. All these cards have similar structure based on the detector hierarchy defined in the SETUP CDF (setup.cdf) file. It looks like in the following example:

SETUP
#
   VSIL   2                  !  Vertex detector
          VSSI               !  Silicon version
          VSLC               !  Liquid capillaries version
   WDRF   3                  !  Tracker
          WCSC               !  MCSC inner option
          WSGC               !  MSGC inner option
          WOHO  2            !  Honeycomb outer tracker
                WOLA         !  Honeycomb large tube size
                WOSM         !  Honeycomb small tube size
   RICH   3                  !  RICH
          RAER               !  Aerogel RICH
          RGS1               !  Gas RICH #1
          RGS2               !  Gas RICH #2
          RHPD               !  RICH HPD detetors
#
.
.
END SETUP

The exact contents of the SETUP file together with default settings for all the subsystems is presented in C.

The detector hierarchy outlined above is used in the program in the following way. Any value set for some detector is propagated to all the subsystems of the detector in question. For example, the data card

DEBG 'ALL ' 1 'VSIL' 3 'VSLC' -1

will set DEBG flag for all the subsystems to 1 except for the VSIL and VSSL which will be set to 3, and VSLC will be set to -1.

In the program it is possible to check the values of the flags via a call to IUVERS function, for example:

     IFLAG = IUVERS('GEOM','MUCH')

will return in IFLAG the value set for the MUCH subsystem in the GEOM data card.

Simulation switches and parameters

 

There is a number of switches defined by means of SIFL data card that are used to control some aspects of the simulation procedure. The SIFL card fills in IFLASI array which is contained in CBFLAG common block. The meaning of IFLASI values are described here.

 
IFLASI(1) 		 (D=1) 		 
                        switches on(1) or off(0) the primary 
                        vertex smearing;

IFLASI(3) (D=1) switches on(1) or off(0) the mixing;

IFLASI(4) (D=1) switches on(1) or off(0) suppressing of curling tracks in the magnetic field;

IFLASI(5) (D=1) switches on(1) or off(0) repeated use of PYTHIA event if a desired event selection is not satisfied;

IFLASI(6) (D=1) defines a number of pile-up events to be merged which are read in through GETP stream;

There is also a number of parameters defined via SIPA data card which are contained in PARASI array (CBWPAR common block).

 
PARASI(1) 		 (D=0.007) 		 
                           of the primary vertex smearing;

PARASI(2) (D=0.007) of the primary vertex smearing;

PARASI(3) (D=5.0) of the primary vertex smearing;

PARASI(4) (D=0.2) Energy threshold for moving charged tracks from STAK to KINE structure when entering tracking detector;

PARASI(5) (D=0.2) Energy threshold for storing bremsstrahlung gammas as decay products for the event history purposes;

PARASI(9) (D=0.7)

PARASI(10) (D=10.0)

PARASI(11) (D=0.0) X-starting point of a test particle (see option TEST in MSLT data card);

PARASI(12) (D=0.0) Y-starting point of a test particle;

PARASI(13) (D=0.0) Z-starting point of a test particle;

SICB data model

General overview of the SICB data model

Reasonable data models proved to be very useful tools helping build an off-line software for large experiments. One of the most well-known examples is ADAMO package [4]. The data model introduces extra level of data abstraction and hides the underlying implementation of the program data structures. Therefore, it represents data in more "human" way as well as takes over the majority of tasks of data handling ( like creating data structures, data storage and retrieval ). It allows to think in terms of "objects" rather than in terms of arrays or pointers facilitating later migration to modern programming technologies. The data model should be simple but serve well the task of the off-line data handling.

The general structure of the SICB data model is a two-level tree as shown in Fig.2

  
Figure: A general structure of the proposed SICB data model.

It is based on a single EVNT bank at the highest level. The FANOUT banks at the next level serve the purpose of supporting the tree structure as well as contain some parameters describing the status and structure of dependent OBJECT banks. Normally these banks are not of interest for a user. The data are stored in the OBJECT banks which have a "table"-like layout.

The set of FANOUT banks is fixed and can not be extended by the user. On the contrary, the user may introduce any number of OBJECT banks assigning each of them to a particular FANOUT bank. One of the FANOUTs is specially dedicated for user defined OBJECT banks.

All the OBJECT banks have a similar structure which could be represented as a table ( Fig.3 ). The OBJECT banks are collections of objects

  
Figure: Tabular layout of the OBJECT bank.

of the same type. Each object is contained in one row in the table. It has a fixed number of parameters (1 through N in Fig.3). The object may have references to other objects in any other OBJECT bank. The references may be of different types (1 through K in Fig.3). The reference type is defined by the type of an OBJECT bank where the referenced objects reside. For example, clusters may have references to constituent cells and to tracks contributing to it. Each reference type may have a variable number of references.

The objects inside the OBJECT bank may be grouped in partitions. In the analysis it is a usual task to select some subset of objects. For example, the user may be interested in hits in just one tracking station, or may want to pick up track segments in just "XZ" view of the vertex detector. The partitions are used contain such subsets of objects that are likely to be frequently used. This reduces overheads of making object selections during the analysis. Still, all the banks can be handled as a whole (without partitioning) as well.

An object is completely described by its parameters and references to other objects. Each object (each row in any OBJECT bank) has a unique Object Identifier (IDOBJ) throughout the whole data structure. This identifier determines unambiguously in which OBJECT bank and in which row the object resides. The list of references for a given object is done in the form of IDOBJs. One can think about IDOBJ as a C-like pointer. Tools for object data access (see below) are based either on sequential object position in a bank or on the (IDOBJ).

It is important that the bank structure descriptions are stored on the file along with the data avoiding conflicts in the case of bank modifications.

Data Definition File

Each OBJECT bank is described in a Data Definition File (DDF) in a format which is well readable and can serve as a bank documentation as well. A proposed format of the DDF is shown in an example below:

#
OBJECT
#
NAME:         WDHT   ! hits in the Tracking Chambers
FANOUT:       WDRE
AUTHOR:       A.Tsaregorodtsev
VERSION:      0.0
PARTITIONS:   13     !  correspond to tracking stations
NOBJECTS:     1000   !  initial number of objects
PARAMETERS:   10     !  number of parameters per object                      
#
# ( Type may be F - float, I - integer, B - bit pattern )
# Name Type   Min   Max  Accuracy
#
  X     F   -5000. 5000.   0.01    !  X position
  Y     F   -5000. 5000.   0.01    !  Y position
  Z     F   -5000. 5000.   0.01    !  Z position
  DX    F       0.   50.   0.01    !  X position error
  DY    F       0.   50.   0.01    !  Y position error
  DZ    F       0.   50.   0.01    !  Z position error
  SLX   F   -5000. 5000.   0.01    !  Slope dX/dZ 
  SLY   F   -5000. 5000.   0.01    !  Slope dY/dZ
  DSLX  F       0.   50.   0.01    !  error of slope dX/dZ 
  DSLY  F       0.   50.   0.01    !  error of slope dY/dZ 
#
REFERENCE:    1
#
# References banks
#
ATMC
#
END OBJECT
#

The bank description is contained between OBJECT and END OBJECT statements. Inside a user should provide a bank NAME (restricted to 4 letters), a name of a supporting FANOUT bank, number of PARTITIONS (may be omitted, default value 1 or no partitioning), number of objects (NOBJECTS) for which to reserve space when creating the bank (may be omitted, default value 1), number of PARAMETERS describing the object followed by the parameters specification. Each parameter has its mnemonics (restricted to 4 letters), type, minimum and maximum value, accuracy (needed to implement data packing). The latter three parameters may be omitted. Further, a number of different types of references is given with names of OBJECT banks corresponding to each reference type. As one can see the DDF format allows various comments and is fairly clear to understand. The DDF can contain any number of OBJECT bank descriptions.

Each OBJECT bank receives its unique name which in the following will be refered to as BNAME. This name is used as a part of various mnemonics and in the names of functions used to access data in the banks. The rule for BNAME construction is simple. The BNAME consists of either just OBJECT bank name or OBJECT bank name with the first letter of the corresponding FANOUT bank prepended in the case when the first letters of the OBJECT bank and its FANOUT bank are not the same. For example, a VSCL OBJECT bank in a VSRE FANOUT bank will have VSCL as a bank name BNAME. A VSVT OBJECT bank in a TRIG FANOUT bank will receive the bank name TVSVT.

A special utility (mddf) interprets the DDF and creates two CMZ sequences: BNAME_BANK and BNAME_FUNC, which can be used directly in the code. Sequence names and other declarations contain the BNAME part described above. These sequences should be included into the code in order to use the mnemonics and statement functions special for a particular bank. The first sequence defines mnemonics for the bank parameters and makes parameter mapping onto the "Window" common block (IUDATA array in +SEQ, UTWINDOW). The second sequence defines a number of statement functions to be used to access data stored in the bank. The reason for defining two sequences for each bank is that according to FORTRAN rules the statement functions should be defined after the last type declaration statement. The need is obvious when more than one bank is used in the subroutine. These sequences should be used together with CBBANK sequence.

All the mnemonics for object parameters positions have a unified form and should be used in the program rather than any explicit numbers to make the code readable and less dependant on later changes in bank definitions. The form is MBNAME_PNAME, where PNAME is an object parameter name as given in the DDF. These mnemonics should be used when getting the object parameters by means of special functions described below.

An alternative way to access data stored in the objects is to retrieve it into a "Window" common block (+SEQ, UTWINDOW). In this case variables mapped onto this common block (see below) have a form BNAME_PNAME. The variable types correspond to those defined in the DDF. This way of access has more overheads of copying data and thus should not be heavily used. It is usually used when storing object to the bank or updating an existing object.

The prepared sequences allow to work with the OBJECT bank in a transparent and efficient way (see example below). One more practical advantage of this approach is that reasonable documentation and appropriate mnemonics will be inevitably available for the user indepedently of the author's diligence.

UB package

This package contains a set of basic subroutines necessary to manage objects in the described data model. The following variables are used in the subroutine's definitions as standard arguments :

Some subroutines of the package make use of a window common block defined in the CMZ sequence $UTWINDOW. This common block contains an array IUDATA/RUDATA which elements are associated with the bank mnemonics through EQUIVALENCE statement.

UBPUT(CHBANK,IPART,IDOBJ*)
Subroutine UBPUT stores one new object prepared in the window common block to the partition IPART of the bank CHBANK. If the CHBANK does not exist it will be automatically created. If IPART=0 the object will be appended at the end of the bank. The subroutine returns IDOBJ of the stored object.

UBPUTA(CHBANK,IPART,IARR,NOBJ,LOBJ*)
Subroutine UBPUTA stores NOBJ new objects prepared in the array IARR to the partition IPART of the bank CHBANK. If the CHBANK does not exist it will be automatically created. If IPART=0 the objects will be appended at the end of the bank. The subroutine returns a list of object identifiers LOBJ of the stored objects. The array IARR should have the following structure: INTEGER IARR(NWBNAME,*) where NWBNAME parameter is defined in the BNAME_BANK sequence.

UBUPDA(IDOBJ)
Subroutine UBUPDA updates an existing object with IDOBJ by the data stored in the window common block.

UBPUTR(IDOBJ,IREF,LREF,NREF)
Subroutine UBPUTR stores NREF references of type IREF for the object IDOBJ which are contained in an array LREF. If there were references of this type stored before they will be overwritten.

UBADDR(IDOBJ,IREF,LREF,NREF)
Subroutine UBADDR adds NREF references of the type IREF contained in the array LREF to the object IDOBJ.

UBGET(CHBANK,NFOBJ,*NLOBJ*,IPART)
Subroutine UBGET returns one or more objects from the bank CHBANK in the window common block according to the values of NFOBJ,NLOBJ,and IPART:

The data in the window common block can be used with BNAME_PNAME variables. If more than one object retrieved in a call to UBGET then they should be accessed in IUDATA/RUDATA arrays in the UTWINDOW sequence assuming the following structure IUDATA(NWBNAME,*)/RUDATA(NWBNAME,*) where NWBNAME parameter is defined in the BNAME_BANK sequence. This will be usually done by putting an array of the proper structure in EQUIVALENCE with IUDATA/RUDATA arrays.

UBGETA(CHBANK,NFOBJ,*NLOBJ*,IPART,IARR)
Subroutine UBGETA is the same as UBGET but the data are returned in an array IARR rather than in the window common block.

UBGETO(IDOBJ)
Subroutine UBGETO returns object specified by IDOBJ in the window common block. It is convenient to use it together with UBUPDA subroutine.

UBGETR(IDOBJ,IREF,LREF*,*NREF*)
Subroutine UBGETR returns references of type IREF (INTEGER) for the object IDOBJ in array LREF (INTEGER). The number of references returned is given in NREF (INTEGER). On the input the NREF argument contains the maximum number of values to be returned in the LREF array.

UBPRESS(CHBANK,CHOPT)
Subroutine UBPRESS compresses the bank CHBANK stripping off unused parts allocated while booking the bank. CHOPT is an options string which can be either blank or 'R' if corresponding reference banks are to be compressed as well.

UBISEARCH(CHBANK,IPART,NPARAM,IVALUE,IDOBJ*)
Subroutine to search bank CHBANK, partition IPART for a first object IDOBJ containing IVALUE in the integer parameter NPARAM.

UBRSEARCH(CHBANK,IPART,NPARAM,RVALUE,EPS,IDOBJ*)
Subroutine to search bank CHBANK, partition IPART for a first object IDOBJ containing RVALUE in the real parameter NPARAM within EPS.

UBISORT(CHBANK,IPART,NPARAM,LID*,*NOBJ*)
Subroutine to sort objects in bank CHBANK in partition IPART in assending order with respect to the integer parameter NPARAM. A sorted list of objects is returned in array LID in the form of IDOBJs. NOBJ is a maximum number of objects on the input and actual number of objects returned in LID on the output.

UBRSORT(CHBANK,IPART,NPARAM,LID*,*NOBJ*)
Subroutine to sort objects in bank CHBANK in partition IPART in assending order with respect to the real parameter NPARAM. A sorted list of objects is returned in array LID in the form of IDOBJs. NOBJ is a maximum number of objects on the input and actual number of objects returned in LID on the output.

UBNOBJ(CHBANK,IPART,NOBJ*)
Subroutine returns number of objects NOBJ in the partition IPART (or in the whole bank if IPART=0) for the bank CHBANK.

UBIDNAME(IDOBJ,CHBANK*) Subroutine returns CHBANK (CH*5) - the name of a bank which contains the object pointed to by IDOBJ.

UBDUMP(IDOBJ)
Subroutine prints the contents of the object pointed to by IDOBJ.

UBMACRO package of statement functions

General purpose functions

The statement functions of the package are defined in two complementary sequences UBMACRO_PARA and UBMACRO_FUNC. The use of the sequences requires CBBANK sequence to be also included. They provide fast access to the data stored and to the information about structural parameters of the banks. The majority of these functions are intended for the internal use by the package. Still some of them may be of interest for a user as well. The functions of general interest are described here.

The functions use two kinds of bank addresses. One is a ZEBRA link to the bank. The user is not encouraged to use this type of access. The other is encoded bank index which has the same format as any IDOBJ. Thus any IDOBJ of the object beloging to the bank may be used as the bank index. The subroutine UBINDEX(CHBANK,LBIND*) returns the bank index LBIND. This way of the bank access is more safe because it would not suffer from unattendant bank relocations due to gabage collections. The following variables are used in the statement functions definitions:

A subset of the functions from the UBMACRO package is described further. The use of this subset is relatively independent of the underlying implementation. For more details check the utcb CMZ library.

L_WORDS_O(LBIND)
Function to return the number of words per object;

L_OBJS_O(LBIND)
Function to return total number of objects;

L_PARTS_O(LBIND)
Function to return the number of partitions;

L_REFS_O(LBIND)
Function to return the number of reference types;

I_OBJ(NPAR,IDOBJ);
R_OBJ(NPAR,IDOBJ)
Functions to return integer or real parameter NPAR for the object IDOBJ;

L_NOBJ(IDOBJ);
Object number inside a partition;

L_IOBJ(IDOBJ);
Object number inside a bank as a whole;

L_NPOBJ(IDOBJ);
Number of partition to which the object pointed by IDOBJ belongs;

NR_OBJ(IREF,IDOBJ)
Number of references of a type IREF for the object IDOBJ;

IR_OBJ(NREF,IREF,IDOBJ)
NREF-th reference of the type IREF for the object IDOBJ.

OBJECT bank specific statement functions

For each OBJECT bank with BNAME a number of statement functions are defined. These functions should be the main means of access to data stored in the banks.

Retriving object parameters

The names of functions used to retrieve parameters of objects are constructed out of the bank name BNAME and parameter name PNAME as declared in the DDF bank definition. There are also mnemonics defined for the parameters numbers to be used in case when this is required by the statement function calling sequence. These mnemonics have the following general form: MBNAME_PNAME. The mnemonics of this type should be used as NPAR argument in the following functions.

BNAME$PNAME(NOBJ);
This function retrieves parameter PNAME of the NOBJ-th object in the BNAME bank;

BNAME$PNAME_P(NOBJ,NPART);
This function retrieves parameter PNAME of the NOBJ-th object in the NPART-th partition of the BNAME bank;

ID_BNAME(NOBJ);
Function to return IDOBJ for the specified object without taking into account bank partitions;

ID_BNAME_P(NOBJ,NPART);
Function to return IDOBJ for the specified object in the partitioned bank.

N_BNAME();
Function to return a number of objects in the whole bank.

The next two types of functions are obsoleted and retained for the sake of backward compartibility:

I_BNAME(NPAR,NOBJ);
R_BNAME(NPAR,NOBJ)
Functions to return integer or real parameter NPAR for the specified object without taking into account bank partitions;

I_BNAME_P(NPAR,NOBJ,NPART);
R_BNAME_P(NPAR,NOBJ,NPART)
Functions to return integer or real parameter NPAR for the specified object in the partitioned bank;

Retriving object references

The names of functions used to retrieve parameters of objects are constructed out of the bank name BNAME and reference bank name RNAME as declared in the DDF bank definition. There are also mnemonics defined for the reference type numbers to be used in case when this is required by the statement function calling sequence. These mnemonics have the following general form: MBNAME_RNAME. The mnemonics of this type should be used as IREF argument in the following functions.

NR_BNAME(IREF,NOBJ);
Function to return the number of references of the type IREF for an object specified by its number NOBJ.

NR_BNAME_P(IREF,NOBJ,NPART);
Function to return the number of references of the type IREF for an object in a partitioned bank.

IR_BNAME(NREF,IREF,NOBJ);
Function to return NREF-th reference of the type IREF for an object specified by NOBJ.

IR_BNAME_P(NREF,IREF,NOBJ,NPART);
Function to return NREF-th reference of the type IREF for an object in a partitioned bank.

In many cases it is known that there is only one reference from a given object to another object (one-to-one or many-to-one relation). Then the reference can be obtained by the following functions:

BNAME$RNAME(NOBJ);
This function retrieves a reference of NOBJ-th object of the bank BNAME to the object in the bank RNAME;

BNAME$RNAME_P(NOBJ,NPART);
This function retrieves a reference of NOBJ-th object in the NPART-th partition of the bank BNAME to the object in the bank RNAME;

How to introduce a new bank

The procedure to introduce a new bank into the program is fairly simple. First of all, the bank description should be prepared in the form of a DDF file. This is the most important step as the bank design is being done here.

Once the DDF file is prepared, it should be processed by means of the mddf utility to prepare two CMZ sequences necessary to work with the bank in the program. Then these sequences should be incorporated into the code.

The bank description (DDF file) should be made known to the program by specifying a stream associated with it in the IOPA data card with a 'D' option.

In the program, before the first storing data to the bank it should be initialized by a call to a UBINTRO subroutine. This subroutine has the following calling sequence:

UBINTRO(CHBANK,LINDBNAME)
, where

CHBANK - (CH) normal bank name in a CHARACTER form;

LINDBNAME - is a name of a special array which definition is contained in the BNAME_BANK sequence. So, this sequence should be included.

Example

A small example of a possible use of the tools to access data stored in the banks is presented here.

...
#include "cbbank.inc"
#include "wdht_bank"
#include "atmc_bank"
#include "ubmacro_para"
...
#include "ubmacro_func"
#include "wdht_func"
#include "atmc_func"
...
C
C  Store track MC information to the ATMC bank object
C
      CALL GFKINE(I,UVERT,UPVERT,IUPART,NUVERT,IBUF,NBUF)
      CALL UCOPY(UVERT,ATMC_XV,3)
      CALL UCOPY(UPVERT,ATMC_PX,4)
      ATMC_NT = IPILE*10000 + I
      ATMC_NV = IPILE*10000 + NUVERT
      ATMC_IPRT = IUPART
      ATMC_NPTR = IBUF(3)
      ATMC_IBOS = IBUF(6)
      ATMC_IFLH = IBUF(1)
      CALL UBPUT('ATMC',1,IDOBJ)
...
C
C  Store a Tracking chamber hit and a reference to the MC track
C
      NCHAMBER = 1      !  Tracking chamber number
      WDHT_X = HIT(1)
      WDHT_Y = HIT(2) 
      WDHT_Z = HIT(3) 
...
      CALL UBPUT('WDHT',NCHAMBER,IDHIT)  ! IDHIT - returned  object ID
      MCTRACKID = 10000*PILEUP + TRACKID
C  find MC track object ID corresponding to the MC track ID MCTRACKID
      UBISEARCH('ATMC',0,MATMC_NT,MCTRAKID,IDTRACK)
C  Store reference to IDTRACK in IDHIT
      CALL UBPUTR(IDHIT,1,IDTRACK,1)
C  Add reference to IDHIT to the list of references in IDTRACK
      CALL UBADDR(IDTRACK,1,IDHIT,1)
...
C
C  Retrieve hits from tracking chamber bank and make a two-dimensional
C  plot of particle density only if the particle is a muon.
C    
      NOBJ = N_WDHT()            ! get number of objects in the bank
      DO I = 1,NOBJ
        X = WDHT$X(I)            ! retrieve X and 
        Y = WDHT$Y(I)            ! Y coordinates
        IDTRACK = WDHT$ATMC(I)   ! get reference to the MC track that 
                                 ! produced this hit

        IPCODE = I_OBJ(MATMC_IPRT,IDTRACK)  ! get track particle ID
        IF(IPCODE.EQ.5.OR.IPCODE.EQ.6) THEN
          CALL HFILL(1,X,Y,1.)
        ENDIF
      ENDDO
...
      CALL UBGETO(IDOBJ)      ! get an object pointed to by IDOBJ 
                              ! into the window common block
      WDHT_X = WDHT_X + DX    ! modify the object parameters
      WDHT_Y = WDHT_Y + DY    
      CALL UBUPDA(IDOBJ)      ! update the existing object
...

User entry points

There are several places in the program where the entries for user subroutines are provided. The following entries are provided:

Utilities

Flavour history code

In the analysis it is often necessary to know the origin of a particle. The full history may be retrieved by unwinding GEANT KINE structures. However, in most cases it is enough to know, for example, that the particle is a descendant of a B-particle decay or it was born in a shower, and so on. Then, it is sufficient to analyse the particle's Flavour History Code (FHC). Every particle has its own FHC which consists of a single 32-bit word with encoded particle history. This history has a form of a decay chain that produced the particle. Each generation in this chain is assigned a special code (not the GEANT code !). Sequence FLHIST containes mnemonics for these codes:

flhist.inc:
...
      PARAMETER ( IPLEPTON  =1,     !  any lepton
     >            IPUPDOWN  =2,     !  particle with just u and d quarks
     >            IPPION    =3,     !  pion
     >            IPSTRANGE =4,     !  particle containing s quark
     >            IPKAON    =5,     !  Kaon
     >            IPKAONS   =6,     !  Ks
     >            IPCHARM   =7,     !  particle containing c quark
     >            IPJPSI    =8,     !  J/psi
     >            IPBEAUTY  =9,     !  particle containing b quark
     >            IPBDZERO  =10,    !  Bd
     >            IPBSZERO  =11,    !  Bs
     >            IPBCHARGE =12,    !  B+,B-
     >            IPGAMMA   =13,    !  gamma
     >            IPFRAGM   =14,    !  fragmentation
     >            IPUNKNOWN =15 )   !  unknown

Each code has 4 bits, so there may be up to 8 generations which is sufficient in almost all the cases. If some particle may be assigned more than one code (e.g. Ks fits both IPSTRANGE and IPKAONS) then it will get the more specific one (i.e. IPKAONS in our example). The last two codes have a special meaning. IPFRAGM means that the decay chain started in the fragmentation phase of the event generator, otherwise it will have IPUNKNOWN instead. The first code in FHC is always either IPFRAGM or IPUNKNOWN. IPUNKNOWN may be the first element in the case of the particle origin from showers, conversions, or any physical process other than decay.

There is a utility subroutine to unwind the particle FHC:

UTFLHIST(IFLHIST,NFLHIST*,IFLARR*)

Input:

IFLHIST (I) - particle Flavour History Code;

Output:

NFLHIST (I) - number of generations;

IFLARR (I) array of a length 8 - code for each generation, where the most recent parent is in the first element of the array.

cm The following is a simple example of a possible use of the FHC:

#include "flhist.inc"
#include "cbbank.inc"
#include "atmc_bank"
#include "atmc_func"
...
      INTEGER IFLHIST,IFLARR(8),NFLHIST
...
      DO I = N_ATMC()
        IFLHIST = I_ATMC(MATMC_IFLH,I)
        CALL UTFLHIST(IFLHIST,NFLHIST,IFLARR)
        IF(IFLARR(1).GE.IPBEAUTY.AND.IFLARR(1).LE.IPBCHARGE) THEN
           !  This is a direct product of a B-particle decay
        ELSEIF(IFLARR(NFLHIST-1).GE.IPBEAUTY  .AND.  
     >         IFLARR(NFLHIST-1).LE.IPBCHARGE) THEN
           !  This particle is a product of a B-particle decay chain
           !  including direct decay
        ELSEIF(IFLARR(NFLHIST).EQ.IPUNKNOWN) THEN
           !  This particle originates from shower (in most cases)
        ELSEIF(IFLARR(1).GE.IPCHARM.AND.IFLARR(1).LE.IPJPSI  .AND.
     >         IFLARR(NFLHIST-1).GE.IPBEAUTY  .AND.  
     >         IFLARR(NFLHIST-1).LE.IPBCHARGE) THEN
           !  This particle appeared through a cascade decay of a B-particle
           !  via charm
        ELSEIF(IFLARR(1).EQ.IPPION            .AND.
     >         IFLARR(NFLHIST).EQ.IPFRAGM     .AND.  
     >         NFLHIST.EQ.2 ) THEN
           !  This particle originates from decayed pion from primary vertex
        ENDIF
      ENDDO

GEANT track/vertex information access tools

These utilities are to be used on in the context of manipulating raw MC data stored in a form of a chain of GEANT structures. Otherwise, ATMC and AVMC banks should be used.

UTGTRACK(IDTRACK,PTRACK*,IPTRACK*,LHITS*,*NHITS*)

Input:

Output:

Returns MC information about the track.

UTGFKINE(IDTRACK,VERT,PVERT,IPART,NVERT,UBUF,NUBUF) and
UTGFVERT(IDVERTX,VERT,NTBEAM,NTTARG,TOFG,UBUF,NUBUF) Subroutines analogous to corresponding GEANT track and vertex data retrieving tools with the only defference that they take MC track and vertex identifiers instead of GEANT track and vertex numbers.

Bank descriptions

A full description of the OBJECT bank contains its name, number and meaning of its partitions, number and nature of the associated REFERENCE banks, number of words describing the object and their meaning. The bank descriptions which follow are contained in the SICB data base and are used by the program each time it runs. The descriptions can also be found here.

Particle coding scheme

Particle codes, charges, masses, life times

Particle codes, charges, masses, life times (continued)

Particle codes, charges, masses, life times (continued)

Particle codes, charges, masses, life times (continued)

Setup Version flags

 

Setup Version flags are defined in the SICB simulation data base in the following file:

$LHCBHOME/sim/vers/db/sicb/setup.cdf

Flags meanings

In general, a flag set to -1 means that the corresponding option is switched off. If some flag is set to 0 and the job reads events from tape than the flag value saved together with the data on tape will be taken. In the following, it is assumed that a detector uses flag 1 to switch on a corresponding facility (SETS - sensitive detector, DIGI - digitization, RECO - reconstruction). If there are different levels of, say, reconstruction, then other values than 1 are described.

GEOM data card

The GEOM data card is used to define various levels of complexity of LHCb infrastructure description. This includes subdivision of the LHCb area into general volumes, the magnet and the magnetic field.

 
CAVE 		 main mother volume
1
standard CAVE;
2
enlarged CAVE to allow Ray Tracing drawings.
REGI 		  LHCb regions level of description. 
         This applies to SMVD,SPEC, ECRI and MUON:
-1
region is switched off completely;
1
region is present without any contents;
2
region contains just the magnet and the beam pipe;
3
same as 2 but also detectors are included with just material but not sensitive media;
4
full region description with sensitive detectors.
MAGN 		 magnet layout:
3
box-like magnetic field;
4
realistic magnetic field map;
MMEC 		  magnet yoke:
3
suppressed showers;
4
full showers;
MFLD  		 magnetic field (applies only for realistic field map):
3
closest value in the field grid;
4
field value is derived by linear interpolation;
MFLT 		 Muon filter blocks:
1
suppressed showers;
2
full showers;

Vertex Detector data cards

Vertex detector VSIL has the following subsystems:

 
VSSI 		  telescope od the Silicon detecors;

VTTD Silicon barrel detector;

VSLC reserved for the Liquid Capillary option.

These options have just one version valid (=1) for SETS,DIGI,RECO data cards.

Tracker data cards

Tracker WDRF has the following subsytems:

 
WINN 		 Inner tracker;

WOUT Outer tracker;

MM MMMMMMMMM ¯ DIGI 'WDRF' 1 naive tracker digitization with just hits smearing;

DIGI 'WDRF' 2 more sophisticated digitization of Honeycomb chambers.

RICH data cards

RICH has the following subsytems:

 
RIC1 		 Upstream RICH;

RIC1 Downstream RICH;

RHPD RICH photon detector;

MM MMMMMMMMM ¯ RECO 'RICH' 1 no RICH particle identification, use the MC information;

RECO 'RICH' 2 simple RICH particle identification based on average number of photons.

E/m calorimeter data cards

E/m calorimeter ECAL has the following subsytems:

 
EFAC 		 imaginary front face detector for storing incoming hits;

EPRE preshower;

ECLR calorimeter itself.

SETS data card

 
SETS 'EFAC' 		 >0 		 forces saving hits at the front face of the Ecal;

SETS 'EPRE' 1 defines the preshower with B_default (high) GEANT thresholds, nonsensitive;

2 defines the preshower with GEANT default (low) thresholds, nonsensitive;

10 defines the preshower with GEANT default (low) thresholds, sensitive;

11 defines the preshower with special Y_default thresholds, sensitive;

SETS 'ECLR' 1 defines the calorimeter with B_default (high) GEANT thresholds, nonsensitive;

2 defines the calorimeter with GEANT default (low) thresholds, nonsensitive;

10 defines the calorimeter with GEANT default (low) thresholds, sensitive;

11 defines the calorimeter with special Y_default thresholds, sensitive;

20 defines the calorimeter with GEANT default (low) thresholds, fast e/m showering algorithm is used, sensitive;

21 defines the calorimeter with special Z_default thresholds, fast e/m showering algorithm is used, sensitive;

DIGI data card

 
DIGI 'ECAL' 		 1 		  
                    simple off-GEANT showers simulation 
                    starting from EFAC hits;

DIGI 'EFAC' >10 MC hits bank is filled in (ECMC);

DIGI 'EPRE' 11 preshower digitization for off-line analysis;

12 preshower digitization for trigger;

13 preshower digitization for both trigger and off-line analysis;

DIGI 'ECLR' 11 build only off-line analysis cells;

12 build only trigger cells;

13 build both trigger and off-line analysis cells;

RECO data card

 
DIGI 'ECLR' 		 1 		 calorimeter clusters reconstruction (ECL0 bank) ;

Hadron calorimeter data cards

Hadron calorimeter ECAL has the following subsytems:

 
HTIL 		 hadron (tile) calorimeter;

HFER iron plate in front of the hadron calorimeter;

SETS data card

 
SETS 'HCAL' 		 1 		  
                      homogenious calorimeter with B_default (high)
                       GEANT thresholds, nonsensitive ;

2 homogenious calorimeter with default GEANT (low) thresholds, nonsensitive ;

10 homogenious calorimeter with B_default (high) GEANT thresholds, sensitive ;

11 homogenious calorimeter with default GEANT (low) thresholds, sensitive ;

20 calorimeter with detailed tile structure with default GEANT (low) thresholds, sensitive ;

The following is valid when SETS 'HCAL' 10:

SETS 'HFER' 10 iron plate in front of the hadron calorimter with B_default (high) GEANT thresholds;

11 iron plate in front of the hadron calorimter with default GEANT (low) thresholds;

DIGI data card


DIGI 'HCAL' 1 simple off-GEANT showers simulation starting from EFAC hits ;

>10 calorimeter cells digitization;

RECO data card


RECO 'HCAL' >10 calorimeter clusters reconstruction;

Muon system data cards

Muon system has a MUCH as a detector name and has just one version valid (=1) for SETS,DIGI,RECO data cards.

Trigger data cards

Trigger has the following subsytems:

 
TMUS 		 muon Level0 strip based algorithm;

TMUP muon Level0 pad based algorithm;

TELN electron Level0 trigger;

THAD hadron Level0 trigger;

TPIL pile-up veto;

TTOP topology Level1 trigger.

For the time being the trigger subsystems are swithced on and off by means of the RECO data card.

Analysis data cards

RECO data card

 
RECO 'AXRE' 		 1 		  
                        track heap is filled with just MC track 
                        information, no pattern recognition;

2 track heap is filled with the results of the track fit, no pattern recognition;

Setup Version default settings

SETUP
#
#                                   GEOM  SETS  HITS  DIGI RECO  DEBG  PRNT
#  Basic volumes - regions
# 
   CAVE                               1    -1    -1    -1   -1    -1    -1
   REGI   4                           4    -1    -1    -1   -1    -1    -1
          SMVD                        4    -1    -1    -1   -1    -1    -1
          SPEC                        4    -1    -1    -1   -1    -1    -1   
          ECRI                        4    -1    -1    -1   -1    -1    -1
          MUON                        4    -1    -1    -1   -1    -1    -1
#
#  Subsystems
#
   VSIL   3                          -1     1     1     1    1    -1    -1 
          VSSI                       -1     1     1     1    1    -1    -1 
          VSLC                       -1    -1    -1    -1   -1    -1    -1 
          VTTD                       -1     1     1     1    1    -1    -1      
   WDRF   2                          -1     1     1     1    1    -1    -1  
          WINN                       -1     1     1     1    1    -1    -1  
          WOUT                       -1     1     1     1    1    -1    -1
   RICH   3                          -1     1     1     1    2    -1    -1 
          RIC1                       -1     1     1     1    2    -1    -1 
          RIC2                       -1     1     1     1    2    -1    -1 
          RHPD                       -1     1     1     1    2    -1    -1 
   ECAL   3                          -1     1     1     1    1    -1    -1 
          EFAC                       -1     10    1     1    1    -1    -1
          EPRE                       -1     10    1     1    1    -1    -1
          ECLR                       -1     10    1     1    1    -1    -1
   HCAL   2                          -1     10    1     1    1    -1    -1 
          HTIL                       -1     1     1     1    1    -1    -1
          HFER                       -1     11    1     1    1    -1    -1
   MUCH                              -1     1     1     1    1    -1    -1
   TRIG   7                          -1    -1    -1    -1    1    -1    -1
          TMUS                       -1    -1    -1    -1    1    -1    -1
          TMUP                       -1    -1    -1    -1    1    -1    -1
          TELN                       -1    -1    -1    -1    1    -1    -1
          TELB                       -1    -1    -1    -1    1    -1    -1
          THAD                       -1    -1    -1    -1    1    -1    -1
          TPIL                       -1    -1    -1    -1    1    -1    -1
          TTOP                       -1    -1    -1    -1    1    -1    -1
   AXRE                              -1    -1    -1    -1    2    -1    -1
#
#  Infrastructure
#   
   MAGN                               4    -1    -1    -1   -1    -1    -1
   MMEC                               4    -1    -1    -1   -1    -1    -1
   MFLD                               3    -1    -1    -1   -1    -1    -1
   PIPE                               3    -1    -1    -1   -1    -1    -1
   MFLT                               1    -1    -1    -1   -1    -1    -1
#
#  Procedures
#    
   RGEN                              -1    -1    -1     1    1    -1    -1 
#
END SETUP

Standard materials

 

#
# Pure materials     A           Z        dens         X_0       abs_l
#
 Vacuum         0.10000E-15 0.10000E-15 0.10000E-15 0.10000E+17 0.10000E+17
 Hydrogen       1.00794     1.0000     0.70800E-01  865.54      717.51
 Deuterium      2.0100      1.0000     0.16200      756.79      337.65
 Helium         4.0026      2.0000     0.12500      754.56      520.80
 Lithium        6.9410      3.0000     0.53400      154.98      137.45
 Beryllium      9.0122      4.0000      1.8480      35.276      40.690
 Bor_10         10.000      5.0000      2.3400     0.00000E+00 0.00000E+00
 Bor_11         11.000      5.0000      2.3400     0.00000E+00 0.00000E+00
 Carbon         12.011      6.0000      2.2650      18.850      38.102
 Nitrogen       14.007      7.0000     0.80800      47.017     108.660
 Air            14.610      7.3000     0.12050E-02  30423.      74689.
 Oxygen         15.999      8.0000     0.14300E-02  23944.      63636.
 Flourine       18.998      9.0000      1.1080     0.00000E+00 0.00000E+00
 Neon           20.180      10.000      1.2070      23.977      80.033
 Sodium         22.990      11.000      0.969      0.00000E+00 0.00000E+00
 Magnesium      24.305      12.000      1.735      0.00000E+00 0.00000E+00
 Aluminium      26.980      13.000      2.7000      8.8926      39.407
 Silicon        28.090      14.000      2.3300      9.3648      45.494
 Phosphor       30.974      15.000      1.82       0.00000E+00 0.00000E+00
 Sulfur         32.066      16.000      2.07       0.00000E+00 0.00000E+00
 Clorine        35.450      17.000      1.56       0.00000E+00 0.00000E+00
 Argon          39.948      18.000     0.16390E-02  10983.    65842.69
 Patassium      39.098      19.000      0.860      0.00000E+00 0.00000E+00
 Calcium        40.078      20.000      1.55       0.00000E+00 0.00000E+00
 Scandium       44.956      21.000      2.98       0.00000E+00 0.00000E+00
 Titanium       47.880      22.000      4.5300      3.5617      27.511
 Vanadium       50.941      23.000      6.10       0.00000E+00 0.00000E+00
 Chromium       51.996      24.000      7.18       0.00000E+00 0.00000E+00
 Manganese      54.938      25.000      7.43       0.00000E+00 0.00000E+00
 Iron           55.850      26.000      7.8700      1.7585      16.760
 Cobalt         58.933      27.000      8.90       0.00000E+00 0.00000E+00
 Nickel         58.693      28.000      8.876      0.00000E+00 0.00000E+00
 Copper         63.546      29.000      8.9600      1.4353      15.056
 Zinc           65.390      30.000      7.112      0.00000E+00 0.00000E+00
 Gallium        69.723      31.000      5.877      0.00000E+00 0.00000E+00
 Germanium      72.610      32.000      5.3230      2.3013      26.395
 Arsenic        74.922      33.000      5.72       0.00000E+00 0.00000E+00
 Selenium       78.960      34.000      4.78       0.00000E+00 0.00000E+00
 Bromine        79.904      35.000      3.11       0.00000E+00 0.00000E+00
 Krypton        83.800      36.000      2.60       0.00000E+00 0.00000E+00
 Neobium        92.906      41.000      9.4100     0.00000E+00 0.00000E+00
 Molybden       95.940      42.000      10.20      0.00000E+00 0.00000E+00
 Silver         107.87      47.000      10.48      0.00000E+00 0.00000E+00
 Cadmium        112.41      48.000      8.63       0.00000E+00 0.00000E+00
 Tin            118.69      50.000      7.31        1.2066      22.30
 Xenon          131.29      54.000      3.057       2.7740      55.28
 Barium         137.33      56.000      3.50       0.00000E+00 0.00000E+00
 Cerium         140.12      58.000      6.637      0.00000E+00 0.00000E+00
 Tungsten       183.85      74.000      19.300     0.35000      9.5855
 Gold           196.97      79.000      18.85      0.00000E+00 0.00000E+00
 Lead           207.19      82.000      11.350     0.56120      17.092
 Bismuth        208.98      83.000      9.37       0.00000E+00 0.00000E+00
 Uranium        238.03      92.000      18.950     0.31662      10.501

In the following there are some mixtures that are defined in a standard file. They can be used as it is or as an example.

#
#  Name                 Number    Density
#                   of components
#
#        Component name         Fraction
# 
 Boron                       2    2.34        
           Bor_10                 -.20
           Bor_11                 -.80        
 B2_O3                       2    2.34        
           Boron                 -2.00         
           Oxygen                -3.00  
 CO_2                        2    1.8182E-03    
           Carbon                -1.0000       
           Oxygen                -2.0000
 SiO_2                      2     2.6400       
           Silicon                -1.0000       
           Oxygen                 -2.0000                 
 CF_4                        2    3.7037E-03    
           Carbon                -1.0000       
           Flourine              -4.0000
 Water                       2    1.0000       
           Hydrogen              -2.0000       
           Oxygen                -1.0000
 Argon_CF_4_CO_2             3    2.14160E-3
           Argon                 -0.3      
           CF_4                  -0.2      
           CO_2                  -0.5       
 Mylar                       3    1.39     
           Carbon                 -5.0      
           Hydrogen               -4.0      
           Oxygen                 -2.0  
 Polystyrene                 2     1.0320       
           Hydrogen               -1.0000       
           Carbon                 -1.0000 
 Optical_fibre               1     1.05         
           Polystyrene            -0.0625 
 Epoxy                       3     1.3000       
           Carbon                 -15.000       
           Hydrogen               -44.000       
           Oxygen                 -7.0000         
 G10_plate                   2     1.7    
           SiO_2                 -0.853   
           Epoxy                 -0.147   
 Aerogel                     3     0.1
           Silicon                -1.0
           Oxygen                 -4.0
           Hydrogen               -4.0 
 Kapton                      3     1.39
           Carbon                 -5.0      
           Hydrogen               -8.0      
           Oxygen                 -2.0

Standard rotation matrices

 

#
#         Thet1   Phi1  Thet2   Phi2  Thet3   Phi3
#
 000D     90.0    0.0   90.0   90.0    0.0    0.0   !  (x,y,z) => ( x, y, z)
 180X     90.0    0.0   90.0  -90.0  180.0    0.0   !  (x,y,z) => ( x,-y,-z)
 XYXD     90.0    0.0   90.0   90.0  180.0    0.0   !  (x,y,z) => ( x, y,-z)
 XZXD     90.0    0.0   90.0  270.0    0.0    0.0   !  (x,y,z) => ( x,-y, z)
 180R     90.0    0.0   90.0   90.0  180.0    0.0   !  (x,y,z) => ( x, y,-z)
 180D     90.0  180.0   90.0   90.0  180.0    0.0   !  (x,y,z) => (-x, y,-z)
 90ZD    -90.0    0.0    0.0    0.0   90.0   90.0   !  (x,y,z) => (-x, z, y)
 90ZS    -90.0    0.0  180.0    0.0   90.0  -90.0   !  (x,y,z) => (-x,-z,-y)
 YZXD    -90.0    0.0  -90.0   90.0    0.0    0.0   !  (x,y,z) => (-x,-y, z)
 180Y     90.0   90.0  -90.0    0.0  180.0    0.0   !  (x,y,z) => ( y,-x,-z)
 180Z     90.0   90.0  -90.0    0.0    0.0    0.0   !  (x,y,z) => ( y,-x, z)
 ZSXD     90.0   90.0  180.0    0.0   90.0    0.0   !  (x,y,z) => ( y,-z, x)
 90XD     90.0   90.0    0.0    0.0   90.0    0.0   !  (x,y,z) => ( y, z, x)
 90YZ     90.0  -90.0  180.0    0.0   90.0    0.0   !  (x,y,z) => (-y,-z, x)
 YXZ3     90.0  -90.0   90.0    0.0  180.0    0.0   !  (x,y,z) => (-y, x,-z)
 YXZ4     90.0  -90.0   90.0    0.0    0.0    0.0   !  (x,y,z) => (-y, x, z)
 YXZ5     90.0  -90.0   90.0  180.0  180.0    0.0   !  (x,y,z) => (-y,-x,-z)
 YXZ6     90.0   90.0  -90.0  180.0    0.0    0.0   !  (x,y,z) => ( y,-x, z)
 90YD      0.0    0.0   90.0    0.0   90.0   90.0   !  (x,y,z) => ( z, x, y)
 90XY      0.0    0.0   90.0  -90.0   90.0    0.0   !  (x,y,z) => ( z,-y, x)
 Z45P     90.0   45.0   90.0  135.0    0.0    0.0   !  (x,y,z) => ( ?, ?, z)
 Z45N     90.0  315.0   90.0   45.0    0.0    0.0   !  (x,y,z) => ( ?, ?, z)
 YXZ1     90.0   90.0  -90.0    0.0  180.0    0.0   !  (x,y,z) => ( y,-x,-z)
 YXZ2     90.0   90.0  -90.0    0.0    0.0    0.0   !  (x,y,z) => ( y, x,-z)

References

1
GEANT. Detector Description and Simulation Tool. CERN program library.
2
CMZ. A Source Code Management System.
3
T.Sjöstrand.PYTHIA 5.7 and JETSET 7.4.CERN-TH.7112/93
4
S.M.Fisher, P.Palazzi, ADAMO Entity-Relationship Programming System,1994

About this document ...

SICB user guide
GEANT3-based simulation package for the LHCb experiment

This document was generated using the LaTeX2HTML translator Version 96.1-g (July 19, 1996) Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.

The command line arguments were:
latex2html -split 0 sicbug.tex.

The translation was initiated by Andrei Tsaregorodtsev on Thu Jun 19 16:14:04 METDST 1997


next up previous

Andrei Tsaregorodtsev
Thu Jun 19 16:14:04 METDST 1997