# 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;

- GGE to create detector C++ class files
- GPE to create physics list C++ class files
- Environment Panel to see and set the Geant4 environment variables which are used in the makefile generated by MOMO
- GAG to start a Geant4 application and to steer its execution
- Gain to start a Geant4 application at a remote site and to steer its execution

MOMO has the extra menus;

1. "Project" menus
   - the button to create a simple working main program which uses G4UIGAG interface and visualization drivers which are set on the MOMO's Env panel,
   - the button to create a Makefile using the environment variables set in the "Environment Panel". This makefile is made so that the environment variables set by the user within the "Environment Panel" oversede the ones defined in the parent terminal/login shell.
   - the button to compile all the files generated by MOMO and a set of companion files to make a running Geant4 executable file.
2. Help menu This document is displayed.

MOMO is helped by the followings;

- A set of companion files complement the C++ source files generated by MOMO. They are stored in the canonical directory structure of Geant4. Among them are mandatory user-defined class and visualization manager. So MOMO with the companion files provide a complete set of running Geant4 simulation, as explained later.
- Examplary MOMO's persistent files of geometry and physics list are also included for demonstration.

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.
  - All necessary class names and their usages of the Geant4 class libraries are applied in automatic C++ code generation
  - All necessary class definition files are included automatically
  - Necessary local variables such as to define the rotation or translation are created when necessary. Naming conventions are explained later.
  - The C++ source codes are saved into files and can be compiled to make a GEANT4 executable.
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
  - A set of companion files are provided to visualize the geometry and to run the simulation with the physics list. Files generated by GGE and GPE must be stored in the canonical sub-directories, therein. Details will be explained later.
  - The stand-alone version of MOMO provides three menu buttons;
    - to generate a simple working main program. User has to supply the name of the main program, which MOMO uses for the G4TARGET.
    - to generate Momomake.gmk makefile. The environment variables set by a user are included in the Momomake.gmk.
    - to compile all. If MOMOHOME variable is defined to designate the position of the companion files, MOMO starts make command. Or user can use this makefile like;

                %make -f Momomake.gmk

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.

- text area to specify the class name. This is mandatory to save data or to create C++ source codes.
- menu buttons; Material editor, Volume editor
  - load, save a persistent file
    - Java Serialization data format (MOMO-standards), the compatibility with the future version of MOMO isn't garuanteed.
    - XML format (not recommended though with limited functions)
  - clear the tables
  - generate cc and hh files using the specified class name (Volume editor)

### 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
   - material from scratch
     The name of an atom, numbers Z and A are taken from the atomic table. User has to specify its density, temperature and pressure. Canonical units and states can be choosen from the listbox.
     Although the scratch table shows the names of the elements in the second column, the corresponding instance in C++ is named "elementX", where "X" represents element's symbol, like "elementH", "elementNa".
   - material by combination (number or fractional ratios).
     When element(s) is(are) chosen in the periodic table of atoms

, it(they) is(are) copied to tha table of scratch(compound) on the pression of "append" or "insert" button.
If user selected multiple elements and pushed "insert" or "append" button of the scratch table, only the first element is copied. When the button of the compound table is pushed, all the selected elements are shown in the third column.
To "insert" a row, user has to focus a row before the click on the menu button. A new row is created just below it.
- User has to type in the name of a compound material, which is employed as the variable name in verbatim.
- A pop-up window is displayed when he focuses and click on a third cell with the label "elements". There, compound by number or by fraction can be specified. The values are copied to the "elements" cell. To confirm, user can enlarge the width of the cell.
- default states (and their canonical names) and values are provided (material state, temperature, pressure).
- canonical physical units of GEANT4 are shown in selectable combo-boxes.
- 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.
  - Only materials used in the logical volumes can be automatically checked and marked as "in Use" state by the "Mark the Used Materials" button on the Logical Volume Table, as seen below.
  - user can add any materials "in Use" to have C++ constructors, even when they aren't used in logical volumes.
- 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.
  - load, append or save a material file
  - exemplary persistent material database file "PDG.g4mt" and PDG.xml taken from the PDG data book are available.
  Not yet implemented are;
  - material from materials,
  - isotope
  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
  - three buttons; "append", "insert" and "delete"
  - the logical volume table;
    Each row in the table corresponds to an instantiation of a Geant4 logical or physical volume constructor. Its arguments are specified in the other cells of the row.
  - the button "Mark the Used Materials"
  - the editor for visualization attributes
    When "create" button is pressed, a color chooser popps up. By choosing a color and typing its name, it is copied in the editor.

  ### 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;
     - The first column is to specify the name of a logical volume.
     - The second column is filled automatically by choosing one of the G4Solid types from the listbox.
       By clicking on the cell, user has a pop-up window to edit its parameters and preview with DAWN.
     - The third column is type-in cell for material name listed in the material editor. All the items already defined in the Material editor are diaplayed in the form of the listbox only to choose one.
     - The fourth column is to specify the visualization attribute's name. All the color names defined in the color chooser lists are displayed to choose one.
  2. Selecting a G4Solid
     All Geant4 solids can be selected from the solid listbox, located at the right of "Select a Solid" label.
     - all CSG solids; box, tube segment, cone segment, symmetric trapezoid, sphere segment, parallel piped, torus segment, HYPE,
     - BREP solids; PolyCone segment and Polygone segment
  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
     - type in parameters and select canonical units of CSG solids
     - add any number of nodes and facets of BREP solids and type in their parameters and select canonical units
     - preview with DAWN with automatically chosen world size
     - save DAWN format file of the solid

     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.
  - C++ code lines are written out to a editor widget and can be edited and saved to a file. But edited file loses the correspondence with the tables contents or the persistent file.
  - The required and necessary header files are automatically included; elements, solid types etc.
  - The order of creating instances is following;
    1. G4Elements,
    2. G4Material,
    3. G4VisAttributes,
    4. G4Solids,
    5. G4LogicalVolume,
    6. Single Positioned Volumes,
    7. Repeated Volumes,
    8. Replicas
    9. return the instance name of the MARS
    Order of instantiation inside each section is from the first row to downward.
  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;
  - user can forget many lengthy class names of particles and processes
  - user can forget to specify necessary class definition files
  - user can forget default values of stepping parameters associated to processes
  - user can forget how to register doublets of a particle and a process
  - it is quite easy to test a physics list
  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

      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`):
  - `architecture.gmk`: defining all the architecture specific settings and paths. System settings are stored in `$G4INSTALL/config/sys` in separate files.
  - `common.gmk`: defining all general GNUmake rules for building objects and libraries.
  - `globlib.gmk`: defining all general GNUmake rules for building compound libraries.
  - `binmake.gmk`: defining the general GNUmake rules for building executables.
  - `GNUmake` scripts: placed inside each directory in the G4 distribution and defining directives specific to build a library (or a set of sub-libraries) or and executable.
  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:
  - `gmake`
    This will start the compilation process for building a kernel library or a library associated to an example. Kernel libraries are built with maximum granularity, i.e. if a category is a compound one, this command will build all the related sub-libraries, _not_ the compound one. The top level `GNUmakefile` in `$G4INSTALL/source` will also build in this case a dependency map `libname.map` of each library to establish the linking order automatically at the `bin` step. The map will be placed in `$G4LIB/$G4SYSTEM`.
  - `gmake global`
    It will start the compilation process to build a single compound kernel library per category. If issued sub-sequently to "gmake", both installations 'granular' and 'compound' libraries will be available (NOTE: will consistently increase the disk space required. Compound libraries will then be selected by default at link time, unless G4LIB_USE_GRANULAR is specified).
  - `gmake bin` or `gmake` (only for examples/)
    It will start the compilation process to build an executable. This command will build implicitly the library associated to the example and link the final application. It assumes _all_ kernel libraries are already generated and placed in the correct `$G4INSTALL` path defined for them.
    The linking order is controlled automatically in case libraries have been built with maximum granularity, and the link list is generated on the fly.
  `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 (!).
  - System configuration

    $CLHEP_BASE_DIR
    Specifies the path where the CLHEP package is installed in your system.

    $G4SYSTEM (!)
    Defines the architecture and compiler currently used. This variable should be set automatically by the installer script "g4install" (in case of installation of Geant4) or by the script "g4config" (in case of pre-installed Geant4 and initial configuration of the user's environment).

  - Installation paths

    $G4INSTALL
    Defines the path where the Geant4 toolkit should be installed. It should be set by the system installer. By default, it sets to $HOME/geant4, assuming the Geant4 distribution is placed in $HOME.

    $G4BASE (!)
    Defines the path to the source code. Internally used to define $CPPFLAGS and $LDFLAGS for -I and -L directives. It has to be set to $G4INSTALL/src.

    $G4WORKDIR
    Defines the path for the user's workdir for Geant4. It is set by default to $HOME/geant4, assuming the user's working directory for Geant4 is placed in $HOME.

    $G4INCLUDE
    Defines the path where source header files may be mirrored at installation by issuing `gmake includes` (default is set to `$G4INSTALL/include`)

    $G4BIN, $G4BINDIR (!)
    Used by the system to specify the place where to store executables. By default they're set to $G4WORKDIR/bin and $G4BIN/$G4SYSTEM respectively. The path to $G4WORKDIR/bin/$G4SYSTEM should be added to $PATH in the user environment. $G4BIN can be overridden.

    $G4TMP, $G4TMPDIR (!)
    Used by the system to specify the place where to store temporary files products of the compilation/build of a user application or test. By default they're set to $G4WORKDIR/tmp and $G4TMP/$G4SYSTEM respectively. $G4TMP can be overridden.

    $G4LIB, $G4LIBDIR (!)
    Used by the system to specify the place where to store libraries. By default they're set to $G4INSTALL/lib and $G4LIB/$G4SYSTEM respectively. $G4LIB can be overridden.

  - Build specific

    $G4TARGET
    Specifies the target (name of the source file defining the main()) of the application/example to be built. This variable is set automatically for the examples and tests placed in $G4INSTALL/examples.

    $G4EXEC_BUILD
    Flag specifying if to use a secondary template repository or not for handling template instantiations at the time of building a user application/example. For internal category tests in Geant4, this variable is already in the related GNUmakefile. It's however not needed for examples and tests in $G4INSTALL/examples, where class names are already mangled and different each other. It applies only on those compilers which make use of template repositories (see Appendix A.2 of this Guide). The secondary template repository is set to $G4TREP/exec.

    $G4DEBUG
    Specifies to compile the code (libraries or examples) including symbolic information in the object code for debugging. The size of the generated object code can increase considerably. By default, code is compiled in optimised mode ($G4OPTIMISE set).

    $G4NO_OPTIMISE
    Specifies to compile the code (libraries or examples) without compiler optimisation.

    $G4NO_STD_NAMESPACE
    To avoid using the std namespace in the Geant4 libraries.

    $G4NO_STD_EXCEPTIONS
    To avoid throwing of exceptions in Geant4.

    $G4_NO_VERBOSE
    Geant4 code is compiled by default in high verbosity mode ($G4VERBOSE flag set). For better performance, verbosity code can be left out by defining $G4_NO_VERBOSE.

    $G4LIB_BUILD_SHARED
    Flag specifying if to build kernel libraries as shared libraries (libraries will be then used by default). If not set, static archive libraries are built by default.

    $G4LIB_BUILD_STATIC
    Flag specifying if to build kernel libraries as static archive libraries in addition to shared libraries (in case $G4LIB_BUILD_SHARED is set as well).

    $G4LIB_USE_GRANULAR
    To force usage of "granular" libraries against "compound" libraries at link time in case both have been installed. The Geant4 building system chooses "compound" libraries by default, if installed.

  - UI specific

    The most relevant flags for User Interface drivers are just listed here. A more detailed description is given also in section 2. of this User's Guide.

    G4UI_USE_TERMINAL
    Specifies to use dumb terminal interface in the application to be built (default).

    G4UI_BUILD_XM_SESSION, G4UI_BUILD_XAW_SESSION
    Specifies to include in kernel library the XM or XAW Motif-based user interfaces.

    G4UI_USE_XM, G4UI_USE_XAW
    Specifies to use the XM or XAW interfaces in the application to be built.

    G4UI_BUILD_WO_SESSION, G4UI_USE_WO
    Specifies to use the WO user interface associated to the OPACS tool.

    G4UI_BUILD_WIN32_SESSION
    Specifies to include in kernel library the WIN32 terminal interface for Windows systems.

    G4UI_USE_WIN32
    Specifies to use the WIN32 interfaces in the application to be built on Windows systems.

    G4UI_NONE
    If set, no UI sessions nor any UI libraries are built. This can be useful when running a pure batch job or in a user framework having its own UI system.

  - Visualization specific

    The most relevant flags for visualization graphics drivers are just listed here. A description of these variables is given also in section 2. of this User's Guide.

    $G4VIS_BUILD_OPENGLX_DRIVER
    Specifies to build kernel library for visualization including the OpenGL driver with X11 extension. It requires $OGLHOME set (path to OpenGL installation).

    $G4VIS_USE_OPENGLX
    Specifies to use OpenGL graphics with X11 extension in the application to be built.

    $G4VIS_BUILD_OPENGLXM_DRIVER
    Specifies to build kernel library for visualization including the OpenGL driver with XM extension. It requires $OGLHOME set (path to OpenGL installation).

    $G4VIS_USE_OPENGLXM
    Specifies to use OpenGL graphics with XM extension in the application to be built.

    $G4VIS_BUILD_OI_DRIVER
    Specifies to build kernel library for visualization including the OpenInventor driver. It requires $OIHOME and $HEPVISDIR set (paths to OpenInventor/HepVis installation).

    $G4VIS_USE_OI
    Specifies to use OpenInventor graphics in the application to be built.

    $G4VIS_BUILD_OIX_DRIVER
    Specifies to build the driver for the free X11 version of OpenInventor.

    $G4VIS_USE_OIX
    Specifies to use the free X11 version of OpenInventor.

    $G4VIS_BUILD_OIWIN32_DRIVER
    Specifies to build the driver for the free X11 version of OpenInventor on Windows systems.

    $G4VIS_USE_OIWIN32
    Specifies to use the free X11 version of OpenInventor on Windows systems.

    $G4VIS_BUILD_OPACS_DRIVER
    Specifies to build kernel library for visualization including the OPACS driver. It requires $OPACSHOME set (path to OPACS installation).

    $G4VIS_USE_OPACS
    Specifies to use OpenInventor graphics in the application to be built.

    $G4VIS_BUILD_DAWN_DRIVER
    Specifies to build kernel library for visualization including the driver for DAWN.

    $G4VIS_USE_DAWN
    Specifies to use DAWN as a possible graphics renderer in the application to be built.

    $G4DAWN_HOST_NAME
    To specify the hostname for use with the DAWN-network driver.

    $G4VIS_NONE
    If specified, no visualization drivers will be built or used.

  - Analysis specific

    $G4ANALYSIS_USE
    Specifies to activate the appropriate environment for analysis, if an application includes code for histogramming based on AIDA. Additional setup variables are required ($G4ANALYSIS_AIDA_CONFIG_CFLAGS, $G4ANALYSIS_AIDA_CONFIG_LIBS) to define config options for AIDA ("aida-config --cflags" and "aida-config --libs"). See installation instructions of the specific analysis tools for details.

  - Directory paths to Physics Data

    $NeutronHPCrossSections
    Path to external data set for Neutron Scaterring processes.

    $G4LEDATA
    Path to external data set for low energy electromagnetic processes.

    $G4LEVELGAMMADATA
    Path to the data set for Photon Evaporation.

    $G4RADIOACTIVEDATA
    Path to the data set for Radiative Decay processes.

  ## 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
     - "Default" button displays the default parameters of the command, if defined
     - "Current" button displays the current value(s), if available
     - "Clear" button clear the contents in the parameters cells
     - "Execute" button starts the command. During the execution, its color isn't in green.
  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.

About the authors