The geometry interface

Overview

The full Hades geometry needed to run a simulation is stored in Oracle:

• ideal geometry
• different alignment versions for the simulation of beam times
• the information, which detectors are present in the beam time or simulation project.

The geometry interface HGeomInterface allows

• to read the geometry from Oracle and to create the geometry in
  • HGEANT
  • the ROOT geometry modeler TGeoManager for browsing, drawing, overlap checking and to use eventually in the future Virtual Monte Carlo (VMC)
• to create ASCII files and to read these files for initialization of HGEANT and the ROOT TGeoManager
• to generate geometry files taking into account the alignment of detectors
• to read the parameters for the hit definition in HGEANT
• to write the geometry and the parameters for hit definition to Oracle

A WebDB interface provides access to the full geometry in folder Geometry.

In the analysis only a small part of the geometry is needed for digitization, tracking, and the event display.
It is stored in parameter containers in the runtime database:

• geometry of cave, sectors, target(s) stored in HSpecGeomPar
• geometry of detectors in parameter containers derived from HDetGeomPar, for example HMdcGeomPar, HTofGeomPar, HTofinoGeomPar, HShowerGeometry.

The Oracle interface reads the ideal geometry of the detector modules and sensitive volumes from the same tables, which contain the full geometry, and fills the parameter containers.
Then it the reads the alignment of the detector modules (if existing) and overwrites the ideal position with the alignment position.
Because all inner parts of a module are stored in Oracle in the reference system of the detector, the sensitive volumes are shifted together with module.

Related Links

• Description of the HADES geometry interface
• The HADES geometry format for volumes
• Material and media definition in HGEANT
• Hit definition in HGEANT

Initialization in HGEANT

See HadesGeant for an overview and how to run and configure HGEANT.

Run id generator

The interface contains a run id generator (similar to the one used by the DAQ) to create a unique run id.
If HGEANT was compiled with Oracle, the interface checks, if this run id is already known to Oracle. If already used for a DAQ or simulation run, a new run id is generated and checked again.

Although you may specify the run id in the GEANT flags (keyword RUNG), you should not do this for official simulations.

Detector setup file

Independent if you read from Oracle or from files, always the full setup of the detectors is read and would be created.
The default setup for the MDC are 24 modules and for the TOF the 8 outer TOF modules plus the 4 Tofino modules in each sector.

To create only a subset of detectors you must specify a file with extension .setup in the configuration file.

Below are two examples how to define subsets:

// ----------------------------------------------------------------------
// Line 1 containes the detector name (lower-case) in [] brackets.
// Line 1 - 6 specifiy the setup in each sector with 1 = "in sectup",
//                                                   0 = "not in setup".
// ----------------------------------------------------------------------
// NOV02 MDC setup
// TOF with 22 modules without Tofino
// (in HGEANT: TOF modules 1 - 22, Tofino 23 - 26)
[tof]
SEC1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
SEC2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
SEC3 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
SEC4 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
SEC5 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
SEC6 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
// NOV02 MDC setup
[mdc]
SEC1 1 1 1 1
SEC2 1 1 0 0
SEC3 1 1 1 0
SEC4 1 1 1 1
SEC5 1 1 0 0
SEC6 1 1 1 0

Remark: A simulation with 22 TOF modules is needed by the kickplane algorithm, which creates new parameters.

Initialization from Oracle

The picture below shows a part from the configuration file.

Special keywords (specified as "keyword" + ": " + "value") and file extensions are used to read and create the geometry:

Keyword	Value
SimulRefRunDb	name of the simulation reference run This defines the geometry version.
HistoryDateDb	history date of the geometry As in analysis by default the geometry of the last parameter release for the simulation project is read from Oracle.
DbSupport	ON (default) = checks in Oracle, if the generated run id exists already OFF turn this feature off.

If you do not want to create the full HADES detector, but only a part, you may spescify the parts in the cofiguration file as

   "keyword for the detector part" + "_gdb"

The picture below shows an example, where only the cave, the sectors and the MDC is created.

Production of geometry ASCII files for HGEANT

The interface allows to store the geometry read from Oracle in ASCII files. These file may then be used for initialization.
It generates separate files for the media and all detector parts with file names

    "keyword for the detector part" + "date and time" + ".geo"

The .hit files for the hit definitions cannot be written to ASCII file. I simply forgot to implement this.

Initialization from Files

Add all (or only a sub-set) ".geo" files and ".hit" files in the configuration file. If a file is missing, the corresponding detector part will not be created.

Initialization of the ROOT TGeoManager

You may create the geometry in the ROOT with a macro using the same configuration file as for HGEANT and you may run the overlap checker. This is very useful, if the geometry was changed in an ASCII file.
With the browser you have access to the geometry volumes, the materials, the overlaps and you can draw 3D pictures.
See example in macros.

Configuration files and macros

See here for full examples of HGEANT configuration files and ROOT macros.

-- IlseKoenig - 01 Jul 2007