Mokka: geometry driver developers

Mokka release $Name: mokka-07-00 $ 



    Primaries with ISTHEP(IHEP) <> 1 in the Pythia input file are accepted but ignored, as described in the Geant4 documentation:
"If the parent particle is an "intermediate" particle, which Geant4 does not have a corresponding G4ParticleDefinition, this parent particle is ignored and daughters are assumed to start from the vertex with which their parent is associated. For example, a Z boson is associated with a vertex and it has positive and negative muons as its daughters, these muons will start from that vertex.  There are some kinds of particles which should fly some reasonable distances and, thus, should be simulated by Geant4, but you still want to follow the decay channel generated by an event generator. A typical case of these particles is B meson. Even for the case of a primary particle which has a corresponding G4ParticleDefinition, it can have daughter primary particles. Geant4 will trace the parent particle until it comes to decay,  obeying multiple scattering, ionization loss, rotation with the magnetic field, etc. according to its particle type. When the parent comes to decay, instead of randomly choosing its decay channel, it follows the "pre-assigned" decay channel. To conserve the energy and the momentum of the parent, daughters will be Lorentz transformed according to their parent's frame. (from "Geant4 User's Guide For Application Developers - Toolkit Fundamentals")."

        Two chapters in this manual concern the Mokka - MySQL  relationships:

3) The Mokka Geometry data model


4) The geometry drivers

    Geometry drivers are piece of C++ code responsible to implement a sub detector as described by the Mokka Geometry data model above. It takes the form of a class with inherits from the VSubDetectorDriver Mokka's kernel abstract class. At execution time, all the geometry drivers Mokka needs to build a given detector model are invoked via their construct() method. The driver's name is a mandatory constructor parameter for the VSubDetectorDriver class. To examine a simple Mokka geometry sub detector driver code like the TPC01, written for the Tesla project, could help you to understand the following explanations.


4.1) The VSubDetectorDriver abstract class

    All sub detector drivers have to inherit from the Mokka VSubDetectorDriver abstract class:

    The sub detector driver developers are concerned by the following methods of the VSubDetectorDriver abstract class:


4.2) The CGAGeometryManager class

  CGA, the "Common Geometry Access" interface, makes the same geometry model available for the simulation, reconstruction and analysis. The Mokka singleton CGAGeometryManager class works as the Mokka G4VUserDetectorConstruction implementation. As any regular Geant4 application, when initializing, the RunManager object calls the CGAGeometryManager's construct() method to build the geometry to be simulated.

    The  CGAGeometryManager's construct() method:


4.3) Materials

    As said above, the CGAGeometryManager's construct() method defines several useful materials to be used by the geometry driver. These materials are CGAGeometryManager's class variables, so to get access you have to use the "CGAGeometryManager::" prefix.

    Some of the actual predefined materials are:

    You are free to define new materials or mixtures. But for coherence proposes it's a good practice to use the already defined in the CGAGeometryManager class, or to ask to add new ones in this list when needed.

4.4) Volumes

    You are free to use all the Geant4 geometry shapes, volumes and placements. Be sure that your topmost logical volumes are placed directly into the logical world volume you got as parameter in the construct() method call. You are free also to define all the visual attributes for your volumes.


4.5) Plugging geometry drivers into CGAGeometryManager class

    To be available, the geometry driver has to be created using the INSTANTIATE macro that is defined in "CGADefs.h". For example, to plug the geometry driver named "mydet" you have to include these two lines in the mydet.cc file:

    #include "CGADefs.h"

    INSTANTIATE(mydet)

   This way there is no need for the detector driver writer to touch other files than those defining the new driver. If the Mokka models database is up to date, you are read to compile and launch Mokka with your detector and your new driver to test it.

5) Sensitive Detectors

    Sensitive detectors are too device dependents to be furnished by the Mokka kernel. So, if your detector driver is able to collect hits, it's your responsibility to define:     Nevertheless, to complain with the persistence implementations:

5.1) The VHits abstract class

    To complain with the Mokka persistence implementations your user defined hit class has to inherit from the abstract class VHits. The VHits abstract class inherits itself from the G4VHit class, so you must not inherit directly your hit class from the G4VHit one.

    The sub detector driver developers are concerned with only by the following methods of the VHit abstract class:

   To complain with the LCIO interface you have to implement also the method
    virtual void Save(LCCollectionVec* ).
    Moreover, when compiling with the LCIO interface the VHit constructor asks for a LCCollectionType name:
      VHit(std::string aLCCollectionType)
 

5.2) VHit concrete implementations available in Mokka

    Mokka provides two generic VHit concrete implementations which we advice the users to use, if possible:
Several hits with the same PID and same cell index can be registered if different particle types in the shower created by this primary cross the same cell. The total energy deposited by the primary PID in the cell is the total of these cells. Several hits with the same (P,S,M,I,J,K) cell index also can be registered if different primaries crossed the same cell. The total energy deposited in a cell during an event is the total of all the lines with the same cell index, indeed different PIDs and, for the same PID, different PDGs.

CellHit co-works with the generic SD sensitive detector available in Mokka for all Tesla-like calorimeters, but you can use it stand-alone when writing a new sensitive detector.
TRKHit co-works with the generic TRKSD00 sensitive detector available in Mokka for all Tesla-like tracker devices, but you can use it stand-alone when writing a new sensitive detector.

5.3) The VSensitiveDetector abstract class

    To complain with the Mokka persistence sub system your user defined sensitive detector class has to inherit from the abstract class VSensitiveDetector. The VSensitiveDetector abstract class inherits itself from the G4VSensitiveDetector class, so you must not inherit directly your sensitive detector class  from the G4VSensitiveDetector one.

    BE CAREFUL: to become active YOU HAVE TO REGISTER your sensitive detector object in the sub detector driver construct() method, thanks to the RegisterSensitiveDetector() VSubDetectorDriver method.

    The sub detector driver developers are concerned with only by the following methods of the VSensitiveDetector abstract class:
 



6) Mokka outputs: event files automatic management

    If your sub detector driver is able to collect hits, surely you'll want to write it to files.  In the current Mokka release it is done automatically for you by the VSubDetectorDriver EndOfEventAction() method. If you over hides the  basic EndOfEventAction() method but you want to keep this feature you have to force a call of this basic method in your implementation.


7) The MySQL Wrapper interface


    The Mokka MySQL Wrapper is an adaptation of a C++/MySQL wrapper wrote by Roland Haenel and available in the MySQL home page. The main extensions were introduced to

    To use our  MySQLWrapper you have to include the MySQLWrapper.hh in your source code with the line

#include "MySQLWrapper.hh"


7.1) MySQL database server connexion

    The MySQL database server connexion is done when you create your Database object. There are several parameters for the Database class constructor, but you are concerned by just the first one, the database name ("db"):

  Database(const char *db,
    const char *host=Control::DBHOST,
    const char *user=Control::USER,
    const char *passwd=Control::DBPASSWD,
    const char *port="");

    All the other values default to the Mokka Control object parameters. It means, by default the geometry driver database will be looked for in the same MySQL server the detector model was found. Normally it should be what you need.

    Remember that the first parameter in the VSubDetectorDriver's construct() method you have to overload is just the database name you should connect to. So, normally the geometry drivers construct() method starts in this way (lets call here the geometry driver as "MyDriver"):

G4bool MyDriver::construct(const G4String &aSubDetectorName,
                                               G4LogicalVolume *WorldLog)
{
...
...
  Database* db = new Database(aSubDetectorName.data());
...

    If Mokka doesn't stop, the connexion is on and the database given as parameter was found in the MySQL server.


7.2) Selections and Tuples

    You can issue database selections thanks to the exec() Database method:

  DBResult *exec(const char *sqlFormat);

    To simplify the MySQL wrapper use, the Database object is now able to remember the last select DBResult you created with the exec() method. So you don't need to keep by yourself a DBResult pointer: just call the exec() Database method with your select command. For example:

    db->exec("select cut_shape_h AS H from endcap_standard_module");

    As in the standard SQL language, the select result is a table with several rows and lines. In the example above the result is a table with just a row, "H", and with zero or more lines depending on the table contents.


7.3) Getting the next Tuple

    To get the next result line from the last created DBResult object, you have to issue a getTuple() Database method call:

    char **getTuple();

    Each time you call the getTuple() Database method, the internal Database line pointer advances by one line in the last created DBResult object. If there is no more line to advance, the getTuple() Database method call returns NULL.

    The getTuple() return char** pointer is the same as the MySQL API mysql_fetch_row() one. But you don't need to deal with it. Just call the getTuple() Database method testing against NULL to be sure you got a new line. To fetch Tuple attribute values, see the following item.

    A typical line by line last created DBResult object access is something as the following:

  db->exec("your select command");
  while(db->getTuple()!=NULL)
   {
     ...
    lines of C++ code using the Tuple fields
     ...
   }

There is not a "rewind" method. If needed you have to re-issue the same select command.
 


7.4) Getting  Tuple attribute values

    You can fetch attribute values by its row names in the current Tuple line with the following Database methods:     Here you have an example:

db->exec("select layer_id, chamber_dim_x/2. AS xdh from barrel_regular_layer");

  while(db->getTuple()!=NULL)
  {
    ...
   G4double XDH = db->fetchDouble("xdh");
   G4int Layer = db->fetchInt("layer_id");
    ...
   }

Note that the row name parameter is an alias defined with an "AS" in the select statement. Or, if you didn't give an alias for the expression you selected, just pass the field name in the table.


7.5) MySQL database server deconnexion

    Please, do not forget to delete the Database object you created to broke the MySQL server connexion and to release internal scratch memory!!! Example:

       delete db;
 
 


It's all, folks!
$Id: geometry_drivers.html,v 1.2 2003/08/01 12:35:52 mora Exp $


Team working on the Geant4 simulation for Tracking Calorimeter:
      fHenri VIDEAU
      Jean-Claude BRIENT
      Paulo Mora de Freitas