This program is part of the Hades Geant simulation packages and creates the geometry and hit definitions in Geant. It was intended to fulfill the following tasks:
This all should be done in the most flexible way as possible to prevent the need of changing and recompiling the program every time one wants to create a special configuration.
The geometry data for the standard geometry are retrieved directly from 3D-CATIA drawings. In the drawings the points of the various volumes and their coordinate systems are marked with names. The CATIA drawings are then converted to IGES format which can be analyzed. With their names the points and coordinate systems are then stored in the database. More information about the geometry stored in Oracle you can find in the documents M. Dahlinger Oracle Database for HADES. With the program geooraout the geometry data can be extracted from the database and written to files, which can be eventually changed and reread by the program.
The geometry of special test beamtimes is not stored in the database. It can be only read from files. How to write these files and the files for hit definitions is described in the document File input for Hades Geometry.
Remark: All code for the geometry program can be found in the
module ggeo of the Hades-CVS. Each header file (*.h) contains
a short documentation of the class.
The Geant-Routine UGEOM calls the c++ routine
using C_Fortran from Cern-library for wrapping.
This is the central routine for reading and creating of the whole geometry. The most of the classes are instantiated here:
These classes are needed for every detector.
The classes for all 'detectors' are successively instantiated and are accessed via a pointer of the type of the base class HGeoSet. This base class is a list class derived from the template container class HNamedList with type HGeoParam. The derived classes are:
In this order these sets are read and created according to the 'filenames' found in the initialization-file.
In the program version geooraout they are only
read and written to output files.
This class holds information used in various parts of the program:
The class oraConnection contains all functions to establish
the connection to the database Oracle. The class oraGeom
contains all functions to get a special information from the database.
The memberfunction
searches the filename with the substring "set" in the
array geoFiles of HGeantInput and connects the input source depending
on the filename-suffix. It opens a file or makes the connection
to the database. The information which input source is actually
used is stored in the element inputFlag as 'f' for file and 'd'
for database. Depending on this flag different read-functions
are called in the further program.
This class is a list class derived from the template container
class HNamendList with type HGeoMedium. Every listelement has
a name and parameters stored in HGeoMedium. The names of the materials
and the media are identical.
The class HGeoMedia has functions to read the media from file
or from database and to store them in the list. When reading from
database this read-function is called every time a volume in this
detector is read. That's different if you want to read a detector
from file. In this case you have to read the media for this detector
also from file, at least these media not already read from the
database and stored in the list.
When reading a medium from file the parameters madfld, maxstep,
maxde, minstep are normally not read. The default values are -1
and the real values are automatically calculated by Geant. If
you want to set these values by yourself, you must type the keyword
AUTONULL in your media-file. After this keyword all media must
contain these additional 4 parameters at the end.
The routine createMedium(...) is called every time a volume is
created in Geant (but the material and the medium is created only
once in Geant!). Here the Geant routines GSMATE, GSMIXT and GSTMED
are called. The routine returns medno, the internal Geant number
ITMED for the medium.
Attention: There are no predefined media!
This class contains all parameters to create a material and a
medium in Geant. The members are:
Attention: MAXCOMP=5 is the maximum number of
components in a mixture. If a material has more then 5 components,
one has to change MAXCOMP in hgeomedium.h.
This class contains all implemented shapes as element classes
(data elements):
All these classes are derived from the base class HGeoBasicShapes
and are accessed in the memberfunctions of HGeoShapes via a pointer
to the actual shape class. This pointer is set by the memberfunction
selectShape(...).
The operations read and write points, calculate Geant shape-parameters
and position a daughter in a mother depend on the shape of the
volume with is actually created. These operations are executed
in the element classes.
The actual Geant parameters are stored in the element class
Every detector has a pointer *pShapes to the class HGeoShapes
and therefore also access to the different shape classes.
This class contains all shape dependent parameters used in the
detector-classes to call the Geant-routines GSVOLU and GSPOS.
It has members (among others):
( FVec is defined as HFloatVec, the Hades vector class for type
float.)
This is the base class for all special shape classes. It has two
members:
this shape. It is initialized in the constructor of the derived
classes.
In this program a 3x3-matrix is always described by a vector with
9 elements listing the matrix rowwise.
The base class has the following virtual memberfunctions:
The first function can read 8 points (8 corners, starting at the
lower left corner of the bottom plane an proceeding in clockwise
direction), so it works for the shapes BOX, TRAP and TRD1. All
other shapes must have their own read-functions in their derived
classes. (A description of the derived classes you can find in
the header-files.)
The 2nd and 3rd functions are purely virtual
and must be defined in the derived classes.
Additionally the base class has a function
to make the Geant rotation and calculate the position of the daughter
volume in its mother. It has also some private functions for matrix
manipulations.
This class is the base class for cave, sectors, coils and all
detectors and is implemented as a list class derived from the
template container class HNamendList with type HGeoParam.
Every element in the list has a name and parameters stored in
HGeoParam. Successively all volumes of a detector are read and
appended to the list.
For explanation: A detector may consist of several
modules sitting in a keepin-volume and each module consists of
several daughters, grand-daughters and so on. First the keepin-volume
will be read and afterwards each module with all volumes inside.
( These subvolumes are read automatically, so you can change the
tree, e.g. by inserting volumes, without recompiling the program.
The only restriction is that the program will not create a daughter
before it has created its mother, so the mother has to show up
in the list before the daughter.)
The functions readDet(...) to read the detector
must be provided in the derived classes. The ones in this base
class are purely virtual.
After the whole detector is read, the detector is created starting
at the beginning of the list. The function createDet(...)
to create it must be provided in the derived class. If a volume
is created with a material having a sensitivity flag sensFlag=1
the function createHits(...) is called. This
function must be also defined in the derived class. In these functions
the Geant parameter IDTYP, the user defined detector type is set.
But the base class contains a lot of helper functions to write
these detector-specific functions in a very short way . The most
important ones are:
The members
are initialized in the constructors of the derived classes. (HString
is the Hades specific string class.)
The member
gives access to the different shape classes in the class HGeoShapes.
The class contains also the parameters needed for the hit definition:
These parameters are read from file via the member function readHits(...).
The parameters NV, CHNMSV and NBITSV needed in the Geant routine
GSDET are set via the routine restoreTree(...)
depending on the actual tree defined in the geometry.
This class stores all geometrical information for one volume read
from database or file.
The members are:
The inout flag is read only for the keepin-volumes
and the mother-volume of a module, not for the volumes sitting
in a module. inout=1 means, the detector / module is build in.
It will be created and with it all volumes sitting inside. (It
does not mean it has to work properly. It may be there only as
a scattering object.) For example you can prevent the creation
of driftchamber number 4 in sector 5 by setting the inout flag
of DR4M5 in the input-file to 0. If the inout flag is 1 it can
be omitted in the input file (default value 1). It is not stored
in Oracle and therefore always set to 1 when reading from database.
The members
store the position and the orientation of the Geant coordinate
system for this volume in the technical coordinate system of the
detector. It's calculated in the shape classes and needed to position
the daughter-volumes properly.
Class for module cave, which consists of one volume with name
CAVE.
class for the Rich detector
It is defined as a volume with name RICH, which
has several subvolumina with names all starting with 'R'.
The Geant parameter IDTYP, the user defined detector type needed
in Geant routine GSDET is defined in the routine createHits(...).
IDTYPE=1
class for sectors
It consists of a maximum of 6 volumes SEC1 ...
SEC6 all with the same shape, medium and dimensions,
which are read only for the first on.
class for driftchambers
It is defined as a set of 4 modules with names starting with "DR1M",
"DR2M", "DR3M",
"DR4M". The 5th character
is the number of the sector (can be omitted if a driftchamber
is positioned directly in the cave). The diftchambers can be positioned
individually in the different sectors. All subvolumes in the driftchambers
have names starting with "D1" ..."D4".
The routine createHits(...) expects sensitive volumes (layers)
with 4-character names. The 4th character is the number
of the layer. The Geant parameter IDTYP is calculated in this
routine: IDTYP=10*N+L where N is the number of
the driftchamber and L the number of the layer.
class for magnet
It is defined as a module "CKIV" in each sector.
The 5th character is the number of the sector. All
subvolumes have names starting with 'C'.
class for Tof wall
It is defined as a set of 22 modules with names starting with
"T01F" ... "T22F".
The 5th character is the number of the sector. The
modules can be positioned individually in the different sectors.
All subvolumes in the modules have names starting with "T01"
..."T22".
In Geant the modules are not positioned in a sector but in keepin-volumes.
The keepin-volume TCM1 ... TCM6 ( The 4th character
is the number of the sector. ) contain the modules 1 - 14, the
keepin-volume TMM1 ... TMM6 contain the module 15 - 18 and keepin-volume
TOM1 ... TOM6 contain the modules 19 - 22. These keepin-volumes
are not read from file or database but calculated in the routine
createKeepIn(...) in this class from the corners of the modules
and the keepin-volume of the Shower-detector. ( The calculation
is only correct if the shape of the modules is a BOX. The geometry
input file for the Tof must contain also the
geometry definition of the keepin-volumes of the Shower detector.)
The keepin-volume in a sector is only created if this sector was
created earlier and at least one module in this keepin-volume
should be created later.
The routine createHits(...) expects sensitive volumes (cells)
with 5-character names. The 5th character is the number
of the cell. The Geant parameter IDTYP is calculated in this routine:
IDTYP=100+10*N+C where N is the number of the
module and C the number of the cell.
class for Shower detector
It is defined as a maximum of 6 keepin-volumes (one in each sector
) with names "SHK1" ... "SHK6".
Each keepin-volume contains 3 modules. The names of these modules
have 5 characters start with the strings "SH1M",
"SH2M" and "SH3M".
The 5th character is the number of the sector. The
keepin-volumes and the modules can be positioned individually.
. All subvolumes in the modules have names starting with "S1"
, "S2" and "S3".
In the routine createHits(...) the Geant parameter IDTYP is calculated
in this routine: IDTYP=50+N where N is the number
of the module.
This class allows to read and create up to 9 independent user
defined modules. These modules are completely independent.
The names of the modules start with the strings "U1KI"
... "U9KI". A module sitting in the
cave has a 4-character name, a module sitting in a sector has
a name with 5 characters where the 5th character is
the number of the sector. All subvolumes of the modules start
with the strings "U1" ... "U9".
Each module can contain one set of sensitive volumes with its
own file for hit definition. The routine createHits(...) expects
sensitive volumes with 4-character names (no copies!). The Geant
parameter IDTYP is calculated in this routine: IDTYP=150+N
where N is the number of the module.
This class allows to read and create all support structures which
are not parts of a detector. All volumes have names starting with
'F' and can be positioned in the cave or in the sectors.
Each volume may have substructures.
Warning: For these volumes the inout flag is not read. It is always
1.
This program is retrieved compiling the code with the flags WITHORACLE
and GEOORA_OUT set in geantdef.h. In this case
the main program main.cc invokes the c++ routine
hgeocreatesetup.cc. The detectors given in the
initialization file geoinifile.cmd
on the local directory are read from Oracle and written to files
without initializing Geant.
class HGeoMedia
class HGeoMedium
class HGeoShapes
class HGeoShapePar
class HGeoBasicShapes
class HGeoSet
class HGeoParam
Class HGeoCave
Class HGeoRich
Class HGeoSect
Class HGeoMdc
Class HGeoCoils
Class HGeoTof
Class HGeoShower
Class HGeoUser
Class HGeoFrames
Program geooraout