MOMO; Integrated GUI desktop for Geant4 development


November 25, 2004
Hajime YOSHIDA
Naruto University of Education

Index

  1. MOMO and its derived versions
  2. How to develop Geant4 detector, physics list, main program, and makefile, using MOMO
  3. GGE Geant4 Geometry Editor
    1. Characteristics
    2. Material Editor and Volume Editor
    3. Menus of GGE
    4. Material Editor
      1. Periodic Table of Elements
      2. Functionalities of the Material Editor
    5. The Logical Volume Editor
      1. Functionalities to define Geant4 logical volumes
    6. The Physical Volume Editor
      1. Limit of Physical volumes Editor
      2. Constructors of G4PVPlacement
      3. Single Positioned Volume
      4. Repeated Translationally Positioned Volumes
      5. Repeated Rotationally Positioned Volumes
      6. Replica in the X, Y or Z direction, Replica in rho, phi or Z direction
    7. Generation of C++ code
      1. Naming conventions in GGE
      2. Default values and combo-boxes
  4. GPE Geant4 Physics Editor
    1. Particle
    2. EM Processes
    3. C++ codes generated by GPE
    4. Persistent file
  5. MOMO's Companion Files
    1. Momomake.gmk generated by MOMO
    2. Main program generated by MOMO
  6. Makefiles and Environment Variables
  7. GAG and Gain
    1. GAG
    2. Gain
TOP 1) MOMO and its derived versions

Momo is conceived as a kind of integrated GUI desktop for Geant4 which combines existing tools like GGE (Geant4 Geometry Editor), GPE (Geant4 Physics Editor), GAG (Geant4 Adaptive GUI) and Gain (Geant4 adaptive interface for network). It also provides user with the capability to create a makefile reflecting his environment variables, to create a simple main program which utilises C++ source codes generated by GGE and GPE and to compile a running application. It is completely written in Java and runs on any platform running Java like Linux, Windows and Mac. Currently supported is Java 1.4 (some functions don't work well with Java 1.5). At present time, there are three versions of MOMO, which have different way to start.
Stand-alone version
It must be started in the console, using "java" command. The jar (Java archive) file MOMO.jar of the standalone version can be downloaded from the site below: Naruto Web server When its environment and a set of companion files are prepared (explained later), MOMO is capable of creating C++ main program, GNU makefile and compiling to make a running program. GAG (Geant4 Adaptive GUI) and gain (Geant4 adaptive interface for network) are available to steer the execution of Geant4 and are integrated in the present version of MOMO.
Java Web Start version
This version is of exactly the same MOMO as the stand-alone version with digital signature. When user clicks it in the Web browser, the jar file is downloaded automatically. Then, it asks him whether he wants to start it, trusting the signature.
MomoPlugin to JAS3
JAS3, when loaded with MomoPlugin.jar, offers similar functionalities as above. The current version of MomoPlugin.jar lacks some functions (creating main program, and makefile) found in the stand-alone version, as explained below. The plugin version can be used in conjunction with G4Plugin which steers the execution of Geant4. MomoPlugin and G4Plugin are available at SLAC. The main program must use G4UIrmi class to connect to G4Plugin. The front-end class G4UIrmi has a stronger point that G4UIGAG in that it is multi-threaded. So, user of G4Plugin + G4UIrmi can stop the execution of a long run without exiting, needless to say the powerful integrated environment for code development, steering the execution of simulation and analysing the results. This manual doesn't treat this interesting plugin.

BACK
2) How to develop detector, physics list, main program, and makefile, using MOMO
Using MOMO, user can create geometry, physics, main C++ classes and a makefile, compile them with Geant4 libraries. Schematical diagram is shown below.
   GGE             GPE            MOMO or User    MOMO Env. Panel  MOMO companions
    |               |                 |              |                   |
 Geometry.cc   PhysicsList.cc    MySimulation.cc  makefile         *.cc *.hh
    |               |                 |              |                   |
 Geometry.o    PhysicsList.o     MySimulation.o   Momomake.gmk          *.o
       \             \                |             /                  /
                                 Mysimulation
                                      /\
                                      ||
                                 GAG / Gain / G4Plugin

All versions of MOMO, in common, offers the following key functions; MOMO has the extra menus;
  1. "Project" menus
  2. Help menu This document is displayed.
MOMO is helped by the followings;
BACK
3) GGE Geant4 Geometry Editor

GGE, or GEANT4 Geometry Editor, is a tabular tool to "create" a detector geometry of GEANT4. From the rows of the tables, filled by user, it generates a complete C++ class code lines for materials and logical volumes. It is capable of limited and relatively simple cases of the full geometry, including physical volumes, i.e., placing of logical volumes.

3-1) Characteristics

BACK
Tables
It provides users with several tables into whose cells users can fill with their own detector parameters. Each row of the tables corresponds to a kind of instantiation or application of a certain method of a class.
Help user with Geant4 defaults
Default values, canonical units of Geant4, pre-defined Geant4 constants etc. are visually provided for user's choice.
C++ code generation
Using the data in the tables, even if they are partial and imcomplete, GGE can generate C++ source codes for a detector, only if the class name of the geometry is supplied.
If user wants so, C++ codes generated by GGE can be a complete description of a detector, including the definition of atoms, materials, solids, color attributes, logical volumes and physical volumes with rotations and translations.
Persistency and Reuse of detector data
Full detector data and material data can be saved in the Java's serialization format or in the XML format a la GDML-1. It can be reloaded for later reuse. XML format a la GDML-1 is limited to materials and logical volumes. But XML file lacks some items in the MOMO's table due to GDML-1's present imcompleteness. Physical volumes aren't supported.
Companion files and Extra "Project" functions

BACK

3-2) Material Editor and Volume Editor


GGE consists of two tabular editors (material and volume) which are interrelated.
The material editor consists of two tables; one for "material from scratch", another for "compound materials".
Volume editor consists of two minor editors; one for "logical volumes" and another for "physical volumes". The logical volume editor allows user to specify complete description of logical volumes, including solid, material, and visualization attribute.
The Physical volume editor, in contrast, supports only limited use-cases ; Single Positioned Volume, Repeatedly Positioned Volumes with incremental copy numbers (translational arrangement or axially symmetric arrangement), and Replicas (in any axis).

Tips!

  1. GGE/MOMO is based on Java's MVC (Model-View-Control) model, so that any changes to any of the tables by a user are automatically reflected to the internal data structure of GGE and thus to C++ codes. This is true at any moment, so that user can get even imcomplete C++ class files at any moment, even without any filled tabular cells, though only the class name is mandatory.
  2. The whole detector description can be saved in a persistent file and can be loaded for later reuse.
  3. GGE employs own naming rules to generate C++ codes from the tables. This will be explained later.

BACK

3-3) Menus of GGE


GGE has a top menu buttons and fill-in text area.

3-4) Material Editor


BACK
The material editor is composed of two minor tables for
  1. "material from scratch" and
  2. "compound materials".
These tables can be enlengthened as will, if necessary. The boundary of the two tables can be moved as will, too.
Every row corresponds to one material (scratch or compound). A row is filled with selected element(s) and default values, when user push the "append" or "insert" button, after selecting a element(s).
BACK

3-4-1) Periodic Table of Elements


The periodic table is popped up, when one of the "append" or "insert" buttons of the tables is pushed.
When an element is chosen by the mouse click, it's label color becomes green. Multiple elements (upto 20 at present) can be chosen simultaneously for compound materials. When a mouse is clicked on the selected element, is is deselected. So, user can choose correct element(s).
The foundamental properties of atoms; Z, A, etc. are pre-built in to the atomic table and are copied automatically to the table. They are also used to create C++, XML and Java serialization files, even though unseen to the user.
The element window can be hidden at any moment by the close button of the window.
BACK

3-4-2) Functionalities of the Material Editor


The following functionalities are implemented;
  1. append, insert, edit and delete a material
  2. The first column "in Use" is to mark the materials used in user's detector (logical volumes). The default value is "in Use", when a row is created at the first time.
  3. input and output from/to persistent material file
    Material tables are saved to a Java's persistent file and can be reused. XML a la GDML format is also provided. Note that GDML is not yet complete and is lacking a part of definitions like material's state etc.
Not yet implemented are; Notice on C++ codes
MOMO doesn't duplicate the C++ instance of an element, but is not protected against possible duplication of "in Use" instances of the same name of compound materials.

3-4-3) A code fragment generated from the dicom.xml; XML file.

// Elements
G4Element* elementH = new G4Element( "Hydrogen", "H", 1. , 1.00794*g/mole );
G4Element* elementC = new G4Element( "Carbon", "C", 6. , 12.011*g/mole );
G4Element* elementN = new G4Element( "Nitrogen", "N", 7. , 14.00674*g/mole );
G4Element* elementO = new G4Element( "Oxygen", "O", 8. , 15.9994*g/mole );
G4Element* elementNa = new G4Element( "Sodium", "Na", 11. , 22.989768*g/mole );
G4Element* elementMg = new G4Element( "Magnesium", "Mg", 12. , 24.305*g/mole );
G4Element* elementP = new G4Element( "Phosphorus", "P", 15. , 30.973762*g/mole );
G4Element* elementS = new G4Element( "Sulfur", "S", 16. , 32.066*g/mole );
G4Element* elementCl = new G4Element( "Chlorine", "Cl", 17. , 35.4527*g/mole );
G4Element* elementK = new G4Element( "Potassium", "K", 19. , 39.0983*g/mole );
G4Element* elementCa = new G4Element( "Calcium", "Ca", 20. , 40.078*g/mole );
G4Element* elementFe = new G4Element( "Iron", "Fe", 26. , 55.845*g/mole );

// Materials from Combination

G4Material* SkeletonSpongiosa = new G4Material("SkeletonSpongiosa",  1159.0*kg/m3, 
     12, kStateUndefined, 273.15*kelvin, 1.0*atmosphere );
SkeletonSpongiosa->AddElement( elementH, 0.085 );
SkeletonSpongiosa->AddElement( elementC, 0.404 );
SkeletonSpongiosa->AddElement( elementN, 0.058 );
SkeletonSpongiosa->AddElement( elementO, 0.367 );
SkeletonSpongiosa->AddElement( elementNa, 0.0010 );
SkeletonSpongiosa->AddElement( elementMg, 0.0010 );
SkeletonSpongiosa->AddElement( elementP, 0.034 );
SkeletonSpongiosa->AddElement( elementS, 0.0020 );
SkeletonSpongiosa->AddElement( elementCl, 0.0020 );
SkeletonSpongiosa->AddElement( elementK, 0.0010 );
SkeletonSpongiosa->AddElement( elementCa, 0.044 );
SkeletonSpongiosa->AddElement( elementFe, 0.0010 );


The above C++ lines are generated from the next fragments of XML file a la GDML which was created by MOMO which reloaded this XML file.

<?xml version="1.0" encoding="UTF-8"?>
<gdml xmlns:gdml="http://cern.ch/2001/Schemas/GDML"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:noNamespaceSchemaLocation="../schema/gdml_1.0.xsd">
<!--skip-->

  <materials>
     <!--Elements-->
     <element name="Hydrogen" formula="H" Z="1">
      <atom value="1.00794"/>
     </element>
     <element name="Carbon" formula="C" Z="6">
      <atom value="12.011"/>
     </element>
     <element name="Nitrogen" formula="N" Z="7">
      <atom value="14.00674"/>
     </element>
     <element name="Oxygen" formula="O" Z="8">
      <atom value="15.9994"/>
     </element>
     <element name="Sodium" formula="Na" Z="11">
      <atom value="22.989768"/>
     </element>
     <element name="Magnesium" formula="Mg" Z="12">
      <atom value="24.305"/>
     </element>
     <element name="Phosphorus" formula="P" Z="15">
      <atom value="30.973762"/>
     </element>
     <element name="Sulfur" formula="S" Z="16">
      <atom value="32.066"/>
     </element>
     <element name="Chlorine" formula="Cl" Z="17">
      <atom value="35.4527"/>
     </element>
     <element name="Potassium" formula="K" Z="19">
      <atom value="39.0983"/>
     </element>
     <element name="Calcium" formula="Ca" Z="20">
      <atom value="40.078"/>
     </element>
     <element name="Iron" formula="Fe" Z="26">
      <atom value="55.845"/>
     </element>

     <!--Materials from Combination-->
     <material name="SkeletonSpongiosa">
         <D type="denstiy" value="1159.0" unit="kg/m3"/>
         <T type="temperature" value="273.15" unit="kelvin"/>
         <P type="pascal" value="1.0" unit="atmosphere"/>
         <fraction n="0.085" ref="H"/>
         <fraction n="0.404" ref="C"/>
         <fraction n="0.058" ref="N"/>
         <fraction n="0.367" ref="O"/>
         <fraction n="0.0010" ref="Na"/>
         <fraction n="0.0010" ref="Mg"/>
         <fraction n="0.034" ref="P"/>
         <fraction n="0.0020" ref="S"/>
         <fraction n="0.0020" ref="Cl"/>
         <fraction n="0.0010" ref="K"/>
         <fraction n="0.044" ref="Ca"/>
         <fraction n="0.0010" ref="Fe"/>
     </material>
<!--skip-->
</gdml>


BACK

3-5) The Logical Volume Editor


The logical volume editor is composed of

3-5-1) Functionalities of the logical volume editor

BACK
Following functionaliteis are implemented;
  1. Defining G4LogicalVolumes
    Each row of the logical vulume table represents an instance of the G4LogicalVolume constructor. User can append, insert or delete a row with corresponding buttons.
    The table has following columns;
  2. Selecting a G4Solid
    All Geant4 solids can be selected from the solid listbox, located at the right of "Select a Solid" label.
  3. After selecting a solid tyle, user pushes the "append" or "insert" button and a new row is created in the table.
  4. By clicking on the "solid" cell (the second column), a pop up window appears to specify solid's parameters. User can
    A code fragment of a logical volume "thintube" of BREP PolyCone generated by MOMO. Words in red are those typed in by a user.
    G4double DzArraythintube   [] = 
         {-1000.0*micrometer, -750.0*micrometer, -500.0*micrometer, -250.0*micrometer, 
          0.0*micrometer, 250.0*micrometer, 500.0*micrometer, 750.0*micrometer, 
          1000.0*micrometer};
    G4double RminArraythintube [] = 
         {1.0*micrometer, 1.0*micrometer, 1.0*micrometer, 1.0*micrometer, 1.0*micrometer, 
          1.0*micrometer, 1.0*micrometer, 1.0*micrometer, 1.0*micrometer};
    G4double RmaxArraythintube [] = 
          {20.0*micrometer, 16.0*micrometer, 12.0*micrometer, 8.0*micrometer, 
           4.0*micrometer, 8.0*micrometer, 12.0*micrometer, 16.0*micrometer, 20.0*micrometer};
    
    G4BREPSolidPCone *solidthintube = new G4BREPSolidPCone("solidthintube",  //its name
    0.0*mrad,  //its start angle
    270.0*deg, //its opening angle
    9,  //its nZ
    DzArraythintube[0],  //z start 
    DzArraythintube,  //z value 
    RminArraythintube,  //rmin 
    RmaxArraythintube );  //rmax
    
    G4LogicalVolume * logicalthintube = new G4LogicalVolume(solidthintube,  //its solid
    carbon,  //its material
    "logicalthintube" , //its name
     0,0,0);
    
    logicalthintube->SetVisAttributes(black);
    

  5. Defining G4Color
    The visualization attribute and its name are required by the logical volumes. They can be defined using a graphical color chooser. Each color's given unique name is listed in the editor panel. The RGB numbers defined by the chooser are taken to generate C++ codes.
    An example of code fragments generated by MOMO
    G4VisAttributes * lightblue= new G4VisAttributes( G4Colour(0/255. ,255/255. ,255/255. ));
    
  6. "Make the used materials" button.
    Clicking this button, GGE scans the materials specified in the logical volume table and marks "in Use" cell (the first column ) of the material tables accordingly. All other materials not used in logical volumes are not marked. Note that only rows marked "in Use" are used to generate C++ codes.

BACK

3-6) The Physical Volume Editor


The physical volume editor consists of five minor tables of different way of displacement of a logical volume. Each table is contained in a tabbed pane.

3-6-1) Limit of Physical volumes Editor


Compared with the logical volume editor, the physical volume one has limited generality. So, if user aren't satisfied with the following simplistic ways to place logical volumes, he can use partially generated C++ codes for logical volumes etc. as a starting point.

3-6-2) Constructors of G4PVPlacement

BACK
Following four types of constructor are implemented, according to the types of rotation and types of the mother volume.
  1. Type 1 constructor = rotation of the frame, physical mother volume
  2. Type 2 constructor = rotation of a body, physical mother volume
  3. Type 3 constructor = rotation of the frame, logical mother volume
  4. Type 4 constructor = rotation of a body, logical mother volume
Next are the example C++ codes generated by MOMO for the above four cases. In the first two cases, words in red are those which user typed in the cells of the editor.
  1. "box-bp" and "box-fp" in the first column to specify the pName, i.e., the name of the unstance of G4PVPlacement
  2. "box" in the second column to spscify the names of their logical volumes, pLogical. All the names already defined in the logical volume panel are displayed to choose one. In this case, one "box" is used to make different physical volumes.
  3. "container" in the pMother, i.e., name of the mother volume. The prefixes "logical" or "physical" are attached according to the type of the mother volume.
pNames are used as postfixes to designate local variables like rotation matrices and rotation angles etc.. On the contrary, several prefixes are used to differentiate instances, like physicalcontainer and logicalcontainer, where only "container" is typed in a cell.
Naming conventions will be explained later.

// Single Positioned Placement 
// Body rotation + physical mother
G4RotationMatrix rotMatrixbox-bp;   // unit rotation matrix
G4double anglebox-bp = 0.0*deg;   // rotational angle
rotMatrixbox-bp.rotateX(anglebox-bp);  // rot matrix

G4VPhysicalVolume *  box-bp= new G4PVPlacement(G4Transform3D(rotMatrixbox-bp,	//rotation 
		 G4ThreeVector(0.0*mm, 0.0*mm, 0.0*mm)),
		 "box-bp",   //its name  (2nd constructor)
		 box,         //its logical volume 
		 physicalcontainer,              //its mother volume 
		 false,                 //no boolean operation 
		 0);                       //copy number 

// Frame rotation + physical mother
G4RotationMatrix rotMatrixbox-fp;   // unit rotation matrix
G4double anglebox-fp = 0.0*deg;   // rotational angle
rotMatrixbox-fp.rotateX(anglebox-fp);  // rot matrix

G4VPhysicalVolume *  box-fp= new G4PVPlacement( new G4RotationMatrix(rotMatrixbox-fp) ,        // Frame rotation 
		 G4ThreeVector(0.0*mm, 0.0*mm, 0.0*mm),
		 "box-fp",   // 1st constructor its name 
		 box,         //its logical volume 
		 physicalcontainer,	//its mother volume 
		 false,	//no boolean operation 
		 0);	//copy number 

// Body rotation + logical mother

G4RotationMatrix rotMatrixbox-bl;   // unit rotation matrix
G4double anglebox-bl = 0.0*deg;   // rotational angle
rotMatrixbox-bl.rotateX(anglebox-bl);  // rot matrix


G4VPhysicalVolume *  box-bl= new G4PVPlacement(G4Transform3D(rotMatrixbox-bl,	//rotation 
		 G4ThreeVector(0.0*mm, 0.0*mm, 0.0*mm)),
		 box,	//its current logical volume(4th constructor) 
		 "box-bl",    //its name 
		 logicalcontainer,              //its mother volume 
		 false,                 //no boolean operation 
		 0);                       //copy number 

// Frame rotation + logical mother

G4RotationMatrix rotMatrixbox-fl;   // unit rotation matrix
G4double anglebox-fl = 0.0*deg;   // rotational angle
rotMatrixbox-fl.rotateX(anglebox-fl);  // rot matrix

G4VPhysicalVolume *  box-fl= new G4PVPlacement( new G4RotationMatrix(rotMatrixbox-fl) ,        // Frame rotation 
		 G4ThreeVector(0.0*mm, 0.0*mm, 0.0*mm),
		 box,	// 3rd constructor its logical volume 
		 "box-fl",    //its name 
		 logicalcontainer,	//its mother volume 
		 false,	//no boolean operation 
		 0);	//copy number 


Following simple placements are provided in GGE. Every placement is contained in independent tabbed pane.
BACK

3-6-3) Single Positioned Volume (SPV)


Each row represents a physical volume which has one-to-one correspondence to a logical volume. The C++ code lines are demonstrated just above.
IMPORTANT!! The world volume must be defined in the first row of this table.
  1. The first column specifies either body or frame rotation.
  2. The second column specifies the instance's name of the physical volume
  3. The third column specifies the name of the logical volume to be placed
  4. The fourth column specifies the type of the mother volume. The mother volume is either null(Master Reference System), logical or physical. The MARS or the world volume must be specified at the first row.
  5. The fifth column specifies the name of the mother volume, if it isn't NULL.
  6. The columns 7, 8 and 9-th specify the translation in the X, Y or Z direction (default is no translation) with a selectable unit of length
  7. The 11-th column specifies the axis of rotation (frame or body); rotation around X, Y or Z axis with an angle in the 12-th column

BACK

3-6-4) Repeated Translationally Positioned Volumes (RTPV Arrangement)


Each row represent a physical volume which consists of any number of copies of a logical volume with incremental copy numbers.
  1. The first to 4-th columns are same as above.
  2. The columns 6, 7 and 8-th specify the position of the first copy
  3. The 10-th column specifies the direction of placement; X, Y or Z direction
  4. The 11-th column specifies the incremental step size of displacement
  5. The last column specifies the number of copies
Next is a fragment of C++ code generated from a line in the table. Here "Boses" is typed in the first column, pName. This word is used as the postfix to designate local variables as well as the loop variable. "box" is the pLogical, i.e., the name of the logical volume. Here the mother's name is typed in as "world" in the pMother cell, and it is physical. The "box" logical volume is translated along X direction from X0 = -100*cm in 10*cm step with the copy numbers "copyBoxes" from 1 to 21.
G4int copyBoxes;
copyBoxes=0;
for (G4int Boxes=1; Boxes<=21; Boxes++){
  G4double transBoxes =-100.0*cm+10.0*cm*(Boxes-1);
  G4VPhysicalVolume * Boxes = new G4PVPlacement(0,      //no rotation 
		 G4ThreeVector(transBoxes, 0.0*cm, 0.0*cm),
		 "Boxes",   //its name 
		 box,         //its logical volume
		 physicalworld,            //its mother volume
		 false,             //no boolean operation
		 copyBoxes++);      //copy number 
}


BACK

3-6-5) Repeated Rotationally Positioned Volumes; (RRPV Arrangement)


Each row represents a physical volume which consists of axially symmetric arrangement of any number of copies of a logical volume with incremental copy numbers.
  1. The columns "move", "pName", "pLogic", "MomType" and "pMother" are same as above.
  2. (X0, Y0, Z0) column specify the position of the center of an axial rotation
  3. "Radius" column specifies a radius of axially symmetric arrangement
  4. "RotAxis" column specifies the rotational axis ; X, Y or Z
  5. "Phi_0" and "dPhi" column specify a starting angle and incremental step angle
  6. The last column specifies the number of copies
A row of the table generates the C++ code lines as below. Here "Circle" is the pName. The logical volume "box" is copied around the Z axis from 0* deg with 30* deg step and with copy number "copyCircle" from 1 to 10. The center of rotation (x0Circle, y0Circle, z0Circle) = (-200*mm, 100*mm, 0.0*mm).
// Active Rotation of Bodies
G4int copyCircle;
copyCircle=0;
G4RotationMatrix rotationMatrixCircle;G4double startCircle = 0.0*deg;
G4double incCircle = 30.0*deg;
rotationMatrixCircle.rotateZ(startCircle);
G4double x0Circle = -200.0*mm;
G4double y0Circle = 100.0*mm;
G4double z0Circle = 0.0*mm;
G4double radiusCircle = 300.0*mm;

for (G4int Circle=1; Circle<=10; Circle++){
  G4double transCircle = startCircle+incCircle*(Circle-1);

  G4double xCircle, yCircle, zCircle;
  xCircle = x0Circle + radiusCircle * cos(transCircle);
  yCircle = y0Circle + radiusCircle * sin(transCircle);
  zCircle = z0Circle;
  G4VPhysicalVolume * Circle = new G4PVPlacement(G4Transform3D(rotationMatrixCircle,	//rotate
		 G4ThreeVector(xCircle, yCircle, zCircle)),
		 "Circle",   //its name 
		 box,         //its logical volume
		 physicalworld,            //its mother volume
		 false,             //no boolean operation
		 copyCircle++);      //copy number 
  rotationMatrixCircle.rotateZ(incCircle);
}


BACK

3-6-6, 7) Replica in the X, Y or Z direction, Replica in rho, phi or Z direction

  1. width (in length or angle) and number of replicas
  2. offset (in length or angle)
  3. logical or physical mother volume
Below is the C++ code lines generated from a row in the table. "Sliced" is the pName (the first column). "box" is the logical volume to be sliced. pMother is "world" and it is the physical volume. The number of replicas along X axis is 1000 with 2.0*micronmeter width and with offset of -1.0*mm.
/ Slicing Translation 

G4PVReplica *  physicalSliced= new G4PVReplica("physicalSliced",  //name
		logicalbox,  // its logical
		physicalworld,  // its mother
		kXAxis, // along Axis
		1000, // No of replicas
		2.0*micrometer, //  width
		-1.0*mm); // offset

Planned but not implemented yet are paremetrised volumes with linear scaling or linear rotation.
BACK

3-7) Generation of C++ code


GGE has two menu buttons to generate the implementation file and class definition file. Here is a sample of automatically generated C++ code which is created from completely skelton tables but with the class name "MyDetector".
//***** Generated by Geant4 Geometry Editor at  Wed Feb 25 20:27:44 JST 2004 *****

//------HeaderFile-
 #include "MyDetector.hh"

#include "G4UnitsTable.hh"

#include "G4VUserDetectorConstruction.hh"

#include "globals.hh"
#include "G4Material.hh"
#include "G4MaterialTable.hh"
#include "G4Element.hh"
#include "G4ElementTable.hh"
#include "G4LogicalVolume.hh"
#include "G4ThreeVector.hh"
#include "G4PVPlacement.hh"
#include "G4PVReplica.hh"
#include "G4SDManager.hh"
#include "G4VisAttributes.hh"
#include "G4Colour.hh"

MyDetector::MyDetector()
{ ; }
MyDetector::~MyDetector()
{ ; }
G4VPhysicalVolume* MyDetector::Construct( )
{
// Elements

// Materials from Combination


// Materials from Scratch


// Visualization attributes


// Logical  Volumes


// Physical Volumes ----  Single Positioned Placement,   Repeated Placement,   Slicing  --------------------------- 


// Single Positioned Placement 


// Repeated Placement Translation 


// Repeated Placement AxialSymmetoric


// Slicing Translation 


// Slicing AxialSymmetric 


// return the physical World



Next is the definition file of this skelton class.

// Geometry Header File 
//   MyDetector.hh generated by Geant4 Geometry Editor at Wed Feb 25 20:27:44 JST 2004  


#ifndef MyDetector_h
#define  MyDetector_h  1

class G4VPhysicalVolume;
#include "G4VUserDetectorConstruction.hh"
class  MyDetector:  public G4VUserDetectorConstruction
   {      public:
      MyDetector();
     ~MyDetector();

      public:
      G4VPhysicalVolume* Construct();
  };
#endif


BACK

3-7-1) Naming conventions in GGE


Knowing GGE's naming convention is helpful to read the generated C++ code as well as using GGE correctly. Look at relevant Geant4 constructors will be very suggestive.
  1. Elements and materials
    1. Elements are named "elementXXX", where XXX stands for the element's symbol in the periodic table.
    2. materials are named just as you have typed in the second column of the material window.
  2. solids and logical volumes
    The "Name" typed in the first (leftmost) column of the "Logical Volume" is used to name the corresponding solid. If the name "world" is given to a logical volume of a Box, the G4Solid has an instance "solidworld".
  3. logical and physical volumes
    1. The strings of the pName (physical or logical) cells filled in the table are used literally as the names of instances.
    2. The instance of a physical volume defined by "pName" has a name prefixed with "physical", i.,e., instance's name is "physical" + pName ( + => string concatenation). "logical" is added to the instance of a logical volume.
    3. In case of SPV (single positioned volume), the columns "pName" (instance of physical volume) and "pLogical" may have the same strings.
    4. In case of RVA (repeated volumes arrangement), "pName" is different from "pLogical" whose copies are repeatedly placed.
  4. All variables are named after their proper instances. See for example, the control variable used in the for loop in the RVA.
    Another examples are arrays to define BREP geometry.

BACK

3-7-2) Default values and combo-boxes

  1. Default optional values of materials GGE provides default values in a pre-filled columns or with the combo-boxes. "Use", "State" and "Unit" columns are equipped with combo-boxes. Temperature and pressure column are pre-filled with 273.15 * kelvin and 1 * atmosphere.
  2. Default values in volumes "Mother Type" is either NULL (mother of all), logical (type 2, 4 constructors) or physical (type 2 or 4 constructors) in G4PVPlacement.


4)GPE: Geant4 Physics Editor BACK

GPE is the GUI tool for the user to be able to define the association between particles and processes. It consists of two parts;
Physics List Table
This is shown in the upper half of the GPE. Every row represents a C++ code line to add the doublet of a particle (the first column) and an EM process (the second column) with the default parameters (from the third through fifth column). The name of a particle can be copied from the table below by a mouse click.
EM particle table and EM process table
Two tables are displayed in tabbed panes, respectively. User select a particle(s) within the particle table and then click the "Append" button. A new row is created in the Physics List Table with the default process "Null". Then, user chooses a process and click the "Change process" button.

BACK

4-1)Particle


GPE helps the user to choose particles to be instantiated.
  1. The user can either choose a set of all particles belonging to a category or to choose an individual particle. The following buttons are shown in the tabbed pane titled "EM Particles".
    • one of either Bosons, Leptons, Mesons, Baryons, Ions
    • all bosons, all leptons, all mesons, all baryons, all ions, all short-lived
    Particles in the category "Shortlived" can be either chosen all at once or not chosen at all.

C++ codes for particles instantiation


GPE generates the "ConstructParticle" method as follows;
void MyPhysicsList::ConstructParticle()
{
     ConstructBosons();
     ConstructLeptons();
     ConstructMesons();
     ConstructBarions();
     ConstructIons();
     ConstructShortLiveds();
}
Then GPE generates codes for each category of particles,
void MyPhysicsList::ConstructBosons()
{
     G4Geantino::GeantinoDefinition();
     ....
     ....    
}

BACK

4-2)EM Processes


With the GPE the user can choose, associate and register a process to a particle. Merits of GPE””could be as follows;
  1. Process Manager
    Information required to register a process to the process manager, i.e., Pointer to the process object and ordering parameter for each DoIt
  2. C++ code
    From a row in the Physics List Table GPE generates C++ lines like;
      G4Aprocess* aProcess;
      G4ParticleDefinition* particle;
    
      G4ProcessManager* pmanager = particle->GetProcessManager();
      if ( aProcess->IsApplicable(*particle) ) {
           pmanager->AddProcess(aProcess, idxAtRest, idxAlongStep, idxPostStep):
        }
    
    
  3. On a selection of a process, the default (predefined) ordering parameters are given. The user can edit them as will.
  4. Available Processes
      Currently implemented in GPE are transportation, electromagnetic and general (only G4Decay).
    • The following electromagnetic processes are available in GPE; standard, muon, xray and lowenergy processes.
    • Transportation and G4Decay are always included by GPE (default).
    • Hadronic processes and models aren't implemented.
    • Excluded processes are parametrization and optical, since both are deeply correlated with the detector geometry.

BACK

4-3) C++ codes generated by GPE

  1. C++ code for "ConstructProcess" method
    void MyPhysicsList::ConstructProcess()
    {
         AddTransportation();
         ConstructEM();
         //ConstructHad();
         ConstructGeneral():
    }
    
    void ExN02PhysicsList::ConstructEM()
    {
      theParticleIterator->reset();
      while( (*theParticleIterator)() ){
        G4ParticleDefinition* particle = theParticleIterator->value();
        G4ProcessManager* pmanager = particle->GetProcessManager();
        G4String particleName = particle->GetParticleName();
    
    // Each if clause corresponds to a row in the PhysicsTable
    
        if (particleName == "gamma") {
          pmanager->AddProcess(new G4PhotoElectricEffect(),ordInActive,ordInActive,ordDefault);
        }
        if (particleName == "gamma") {
          pmanager->AddProcess(new G4ComptonScattering(),ordInActive,ordInActive,ordDefault);
        }
        if (particleName == "gamma") {
          pmanager->AddProcess(new G4GammaConversion(),ordInActive,ordInActive,ordDefault);
        }
        if (particleName == "gamma") {
          pmanager->AddProcess(new G4PolarizedComptonScattering(),ordInActive,ordInActive,ordDefault);
        }
        if (particleName == "e-") {
          pmanager->AddProcess(new G4MultipleScattering(),ordInActive,1,1);
        }
    .....
    .....
    
  2. C++ code for ConstructGeneral()
    #include "G4Decay.hh"
    
    void ExN02PhysicsList::ConstructGeneral()
    {
      G4Decay* theDecayProcess = new G4Decay();
      theParticleIterator->reset();
      while( (*theParticleIterator)() ){
        G4ParticleDefinition* particle = theParticleIterator->value();
        G4ProcessManager* pmanager = particle->GetProcessManager();
        if (theDecayProcess->IsApplicable(*particle)) {
          pmanager ->AddProcess(theDecayProcess);
          pmanager ->SetProcessOrdering(theDecayProcess, idxPostStep);
          pmanager ->SetProcessOrdering(theDecayProcess, idxAtRest);
        }
      }
    }
    
    
  3. GPE generates a header file of user's physics list class.
  4. C++ for default cut value can be generated, using user's cut length. (no cut-by-region).
    void ExN02PhysicsList::SetCuts()
    {
    // defaultCutValue you have typed in is used
    
      if (verboseLevel >1){
        G4cout << "ExN02PhysicsList::SetCuts:";
      }
      SetCutsWithDefault();
    }
    
BACK

4-4) Persistent file


The class name and default cut value are indispensable to make C++ code or to save to the persistent file. The contents of the GPE can be saved to a file in the Java serialization format and can be reused.
5)MOMO's Companion Files

The companion files are included under MomoHome. The files in red are created by MOMO.
[~/MomoPlugin]$ ls -R MomoHome
MomoHome:
MomoN02Test.cc             PDGmaterials.xml  include/
MomoN02MyDetector.g4dt     README             src/
MomoN02PhysicsList.g4ph     Momomake.gmk    dicomVolume.xml    vis.mac

MomoHome/include:
MomoEventAction.hh    MomoN02PhysicsList.hh          MomoRunAction.hh
MomoN02MyDetector.hh  MomoPrimaryGeneratorAction.hh  MomoVisManager.hh

MomoHome/src:
MomoEventAction.cc    MomoN02PhysicsList.cc          MomoRunAction.cc
MomoN02MyDetector.cc  MomoPrimaryGeneratorAction.cc  MomoVisManager.cc
BACK

5-1)Momomake.gmk generated by MOMO


Following is the automatically generated "Momomake.gmk" file. The word in red is the target name specified by the user. In the example, G4WORKDIR and G4BINDIR (in orange) are specified in the relative path (period). Note that the present directory means where momo was started.
##### GNUmakefile #####
# ----------------------------------------------------------
# Script defining rules and paths for making binaries.
# ----------------------------------------------------------
# Automatic creation of GNUmakefile for Momo environment.
# with users selection of G4TARGET, UI and VIS variables
#  Momo is the name of legendary samurai who conquered bad geants. ----   H. Yoshida.

name := MomoN02Test
G4TARGET := $(name)
G4EXLIB := true

# Vis/GUI used
G4VIS_USE_DAWN := 1
G4VIS_USE_DAWNFILE := 1
G4VIS_USE_OPENGLX := 1
G4VIS_USE_VRML := 1
G4VIS_USE_VRMLFILE := 1
# Vis/GUI built
G4VIS_BUILD_DAWN_DRIVER := 1
G4VIS_BUILD_DAWNFILE_DRIVER := 1
G4VIS_BUILD_OPENGLX_DRIVER := 1
G4VIS_BUILD_VRML_DRIVER := 1
G4VIS_BUILD_VRMLFILE_DRIVER := 1

# General Envs defined
G4SYSTEM:=Linux-g++
G4INSTALL:=/home/yoshidah/geant4.6.0.p01
G4WORKDIR:=.
G4BINDIR:=./bin/Linux-g++
G4USE_STL:=1
G4LIB_BUILD_STATIC:=1
G4LEDATA:=/home/yoshidah/G4DATA/G4EMLOW2.2
G4LEVELGAMMADATA:=/home/yoshidah/G4DATA/PhotonEvaporation
G4REALSURFACEDATA:=/home/yoshidah/G4DATA/RealSurface1.0

ifndef G4INSTALL
   G4INSTALL = ../../..
endif

.PHONY: all
all: lib bin

  include $(G4INSTALL)/config/binmake.gmk

5-2)Main program generated by MOMO

BACK
All the following codes are automatically generated by MOMO. The red words are user defined class names, which MOMO uses for code generation. The words in orange can be changed as will.
//##### MOMO Main program #####
//# ----------------------------------------------------------
//# Automatic creation of the main program for Momo environment.
// 2003 December, updated for  geant4.6.0
// --------------------------------------------------------------
//   MomoN02Test.cc generated by Geant4 Momo
//     at Tue Feb 24 09:23:50 JST 2004  


// This code implementation is the intellectual property of
// the  GEANT4 collaboration.
//
// By copying, distributing or modifying the Program (or any work
// based on the Program) you indicate your acceptance of this statement,
// and all its terms.
//
// 
#include "G4RunManager.hh"
#include "G4UImanager.hh"
// Your choice of User Interface driver
#include "G4UIGAG.hh"
// Detector geometry generated by Momo's GGE
#include "MomoN02MyDetector.hh"
// Physics List generated by Momo's GPE
#include "MomoN02PhysicsList.hh"
// Momo's default PrimaryGeneratorAction
#include "MomoPrimaryGeneratorAction.hh"
#include "MomoRunAction.hh"
#include "MomoEventAction.hh"
#ifdef G4VIS_USE
#include "MomoVisManager.hh"
#endif
int main()
{
  // Construct the default run manager
  G4RunManager* runManager = new G4RunManager;
  // set mandatory initialization classes
  runManager->SetUserInitialization(new MomoN02MyDetector);
  runManager->SetUserInitialization(new MomoN02PhysicsList);
#ifdef G4VIS_USE
  // visualization manager
  G4VisManager* visManager = new MomoVisManager;
  visManager->Initialize();
#endif
  // set mandatory user action class
  runManager->SetUserAction(new MomoPrimaryGeneratorAction);
  // set user action classes to visualise trajectories
  runManager->SetUserAction(new MomoRunAction);
  runManager->SetUserAction(new MomoEventAction);
  // Initialize G4 kernel
  runManager->Initialize();
  // get the pointer to the User Interface manager 
  G4UImanager* UI = G4UImanager::GetUIpointer();
      G4UIsession * session = new G4UIGAG;
      session->SessionStart();
      delete session;
  // job termination
#ifdef G4VIS_USE
  delete visManager;
#endif
  delete runManager;
  return 0;
}



The following document is taken from the Geant4 documents to help MOMO's Environment Panel.
10.5 Makefiles and Environment Variables BACK




This section describes how the GNUmake infrastructure is implemented in Geant4 and provides a quick reference guide for the user/installer about the most important environment variables defined.

10.5.1 The GNUmake system in Geant4

As described in section 2.7.1.1 of this manual, the GNUmake process in Geant4 is mainly controlled by the following GNUmake script files (*.gmk scripts are placed in $G4INSTALL/config): To build a single library (or a set of sub-libraries) or an executable, you must explicitly change your current directory to the one you're interested to and invoke the "gmake" command from there ("gmake global" for building a compound library). Here is a list of the basic commands or GNUmake "targets" one can invoke to build libraries and/or executables: lib/ bin/ and tmp/ directories

The $G4INSTALL environment variable specifies where the installation of the Geant4 toolkit should take place, therefore kernel libraries will be placed in $G4INSTALL/lib. The $G4WORKDIR environment variable is set by the user and specifies the path to the user working directory; temporary files (object-files and data products of the installation process of Geant4) will be placed in $G4WORKDIR/tmp, according to the system architecture used. Binaries will be placed in $G4WORKDIR/bin, according to the system architecture used. The path to $G4WORKDIR/bin/$G4SYSTEM should be added to $PATH in the user environment.


10.5.2 Environment variables

Here is a list of the most important environment variables defined within the Geant4 GNUmake infrastructure, with a short explanation of their use. We recommend _not_ to override (explicitly or by accident) those environment variables listed here and marked with (!).

10.5.3 Linking External Libraries with Geant4

The Geant4 GNUmake infrastructure allows to extend the link list of libraries with external (or user defined) packages which may be required for some user's applications to generate the final executable.

10.5.3.1 Adding external libraries which do *not* use Geant4

In the GNUmakefile of your application, before including binmake.gmk, specify the extra library in EXTRALIBS either using the -L...-l... syntax or by specifying the full pathname, e.g.:
  EXTRALIBS := -L<your-path>/lib -l<myExtraLib>
or
  EXTRALIBS := <your-path>/lib/lib<myExtraLib>.a
You may also specify EXTRA_LINK_DEPENDENCIES, which is added to the dependency of the target executable, and you may also specify a rule for making it, e.g.:
  EXTRA_LINK_DEPENDENCIES := <your-path>/lib/lib<myExtraLib>.a

  <your-path>/lib/lib<myExtraLib>.a:
        cd <your-path>/lib; $(MAKE)
Note that you almost certainly need to augment CPPFLAGS for the header files of the external library, e.g.:
  CPPFLAGS+=-I<your-path>/include
See table 10.5.1.

 # --------------------------------------------------------------------
 # GNUmakefile for the application "sim" depending on module "Xplotter"
 # --------------------------------------------------------------------

 name := sim
 G4TARGET := $(name)
 G4EXLIB := true

 CPPFLAGS  += -I$(HOME)/Xplotter/include
 EXTRALIBS += -L$(HOME)/Xplotter/lib -lXplotter
 EXTRA_LINK_DEPENDENCIES := $(HOME)/Xplotter/lib/libXplotter.a

 .PHONY: all

 all: lib bin

 include $(G4INSTALL)/config/binmake.gmk

 $(HOME)/Xplotter/lib/libXplotter.a:
         cd $(HOME)/Xplotter; $(MAKE)
Table 10.5.1
An example of a customised GNUmakefile for an application or example using an external module not bound to Geant4.

10.5.3.2 Adding external libraries which use Geant4

In addition to the above, specify, in EXTRALIBSSOURCEDIRS, a list of directories containing source files in its src/ subdirectory. Thus, your GNUmakefile might contain:
  EXTRALIBS += $(G4WORKDIR)/tmp/$(G4SYSTEM)/<myApp>/lib<myApp>.a \
               -L<your-path>/lib -l<myExtraLib>
  EXTRALIBSSOURCEDIRS += <your-path>/<myApp> <your-path>/<MyExtraModule>
  EXTRA_LINK_DEPENDENCIES := $(G4WORKDIR)/tmp/$(G4SYSTEM)/<myApp>/lib<myApp>.a

  MYSOURCES := $(wildcard <your-path>/<myApp>/src/*cc)
  $(G4WORKDIR)/tmp/$(G4SYSTEM)/<myApp>/lib<myApp>.a: $(MYSOURCES)
        cd <your-path>/<myApp>; $(MAKE)
See Table 10.5.2.

# -----------------------------------------------------------------
# GNUmakefile for the application "phys" depending on module "reco"
# -----------------------------------------------------------------

name := phys
G4TARGET := $(name)
G4EXLIB := true

EXTRALIBS += $(G4WORKDIR)/tmp/$(G4SYSTEM)/$(name)/libphys.a \
             -L$(HOME)/reco/lib -lreco
EXTRALIBSSOURCEDIRS += $(HOME)/phys $(HOME)/reco
EXTRA_LINK_DEPENDENCIES := $(G4WORKDIR)/tmp/$(G4SYSTEM)/$(name)/libphys.a

.PHONY: all
all: lib bin

include $(G4INSTALL)/config/binmake.gmk

MYSOURCES := $(wildcard $(HOME)/phys/src/*cc)
$(G4WORKDIR)/tmp/$(G4SYSTEM)/$(name)/libphys.a: $(MYSOURCES)
	cd $(HOME)/phys; $(MAKE)
Table 10.5.2
An example of a customised GNUmakefile for an application or example using external modules bound to Geant4.


7. GAG and Gain


7-1 How to use GAG

BACK
Usage of GAG is simple.
  1. Click the GAG tab and open the GAG's pane
  2. Click the top left Geant menu and its "Start" button
  3. Choose the Geant4 binary file, using the file chooser and click on it
  4. After a moment, the Geant4 command tree (at left) and parameter panel (at right) are displayed. AT the lower panel is displayed the outputs from Geant4 application.
  5. Click on the nodes or leaves make their help diaplayed. Commands in the opaque characters are inactive ones.
  6. Parameters are either chosen from the list or typed in.
  7. Four buttons are available
  8. Output from the Geant4 are shown in the lower window, if "Log_to_Terminal" button is cheched. This button can be unchecked at any time. "Log_to_File" button can be also cheched or unchecked at any time.
  9. If you want to interrupt the execution, "Kill_Geant4" button is used.

7-2 How to use Gain

BACK

What is Gain?

Gain(Geant4 adaptive interface for network) is a networked GUI tool based on GAG. It inherits almost all features of GAG and has new features to make use of Geant4 running at (a) remote machine(s).

Gain runs on a client machine (Windows or Linux), while Geant4 runs on a remote or local server (Linux or Solaris).

It provides two ways to connect to the remote server; SSH mode and Gain socket mode. SSH mode is strongly recommended, since it is as safe as remote SSh connection and it requires G4UIGAG as the Geant4's interface.

Gain SSH mode
Gain has a SSH client fuction and use it to connect to a remote server. Geant4 compiled with G4UIGAG class can be connected to Gain client. When a SSH connection is established after the authentication, Gain displays the remote file browser with which user can choose a Geant4 executable and make it run. Data are encrypted during their transfer and are decripted at both side. So, some CPU power is required for a client machine, if a large amount of data are transfered from the running Geant4 to Gain.
Output from the remote Geant4 are displayed on the Gain console. This console can be used as a normal SSH console and you can type in command directly.
Pluriel remote sessions can be accepted, each displayed in a separate tabbed pane. A console is attached to each pane/session.
Gain socket mode
Gain uses its own way of connecting to a remote server. Remote Geant4 must be compiled with G4UIGainServer class which is distributed in the standard Geant4 package. In this mode, user has to make a Geant4 executable run on the remote server, after having logged in to the remote machine. G4UIGainServer acts as a network server and tells the number of port available for the Gain client. Gain client, after specifying the server and port number, is allowed to connect to the Geant4. Geant4 output

How to use Gain

The figure shows a scene when Gain is running in Gain socket mode.

In this example, two tabbed panes are displayed to run remote Geant4s running on different servers.

  1. Gain is started on the Cygwin console. Gain can be started with Java Web Start.
  2. Top menu to connect to a server or close (kill) the running G4ant4 or finish Gain.
  3. The window to choose SSh or Gain socket; now SSHINTERFACE is focused
  4. After typing in the remote host name, SSH login window is shown.
  5. When SSH login is accepted, Gain shows the remore File Chooser. Geant4 with G4UIGAG interface can be started from this chooser.
  6. When Geant4 is started, Geant4 initialisation output are shown on the cygwin console.
  7. After the initialisation phase, command tree window is available on Gain.
  8. Then, the Gain console is shown below the command tree window. See the hardcopy of the whole Gain window. This console is the SSH console, so that you can type in Geant4 commands in stead of selecting them in the above command panel.
    You can shrink the console by single click on the triangle at the left border.
  9. Two ways of ending Geant4 execution are provided. The command tree provides "exit" command which is just the "exit" of Geant4. On the top menu, "Close one" menu is to send CTRL + C to the running Geant4 process. It can be sent at any moment.

Notices on Gain console


  • At present, Gain's console displays ecerything G4cout from Geant4 with G4UIGAG interface. So, strings employed for Gain protocols are displayed. Please ignore lines starting with @@.
  • Gain console demands heavy Windows (X or Windows) power. So, with old graphic accelerators like S3 etc. which are yet common on Linux platforms, speed of console may be very slow. In such cases, shrinking the console pane is a good way to speed up the execution.
  • We have tested Gain over the Internet for a session of more than 24 hours. On Windows XP, We observed some curious deformed tree icons during the session, but the functions were correct and they became normal after some elapsed time.
    Here is the copy of the long run.
  • The console provides a session of G4UIterminal, and NOT G4UItcsh, at present.
  • If you type "exit" on the console, the execution of Geant4 is stopped. The console is yet a usual ssh console, while the upper windows for the command tree is losing connection to Geant4. If you type in "exit" on the console, it end the ssh session and the whole Gain will be destroyed.

yoshida

About the authors