Description of the program geoora for the HADES Geometry

( updated April 14, 1998 by Ilse Koenig )


Introduction


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.

Is was intended to retrieved the geometry data directly from 3D-CATIA drawings. In these 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.
This way is quite time consuming and actual 3D-CATIA drawings are not availible for all detectors. Additionally the requirements for Geant imply some simplifications and modifications, which cannot be retrieved from the drawings. Therefore the actually used geometry definitions (except for MDC) was written directly into files. Using these files the database was then updated with the program geooraupdate.
How to write the input files for the geometry and the media and hit definitions is described in the document File input for Hades Geometry.

To save old geometry and media definitions in the database the database tables were redesigned and a complete version management was introduced. The new interface to read from Oracle was designed for the special needs of the Geant program which reduced SQL-overhead and made the reading faster.
With the program geooraout the geometry data ( the actual version or an old version valid at a certain date) can be extracted from the database and written to files, which can be eventually changed and reread by the program.

More information about Oracle you can find in the documents of M. Dahlinger Oracle Database for HADES.

Remark: All code for the geometry program can be found in the module ggeo and gora (for the interface to Oracle) of the Hades-CVS. Each header file (*.h) contains a short documentation of the class.


Program Flow


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.


Class structure


Fig 1: Container classes for detectors and media.



ps-file of container classes


class HGeoInfo

This class holds information used in various parts of the program:

The class oraConnection in CVS-module ora by M. Dahlinger contains all functions to establish the connection to the database Oracle.
The class HGeoOraRead in CVS-module gora contains all functions to read the geometry and media data for Geant 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.


class HGeoMedia

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!


class HGeoMedium

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.


class HGeoShapes

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.


class HGeoShapePar

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.)


class HGeoBasicShapes

This is the base class for all special shape classes. It has three members:

nCorners and cgRot are 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 functions calcShape and posShape 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.


class HGeoSet

This class is the base class for cave, sectors, coils, support structures 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.


class HGeoParam

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 additional information from the database. In Oracle the transformation in stored relative to the lab system and the transformation relative to the mother volume (needed by Geant) is calculated in the program.

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 HGeoCave

Class for module cave, which consists of one volume with name CAVE.


Class HGeoRich

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 HGeoSect

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 HGeoMdc

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 HGeoCoils

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 HGeoTof

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 HGeoShower

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.


Class HGeoUser

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.


Class HGeoFrames

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.


Program geooraout


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.