November 25, 2004
Hajime YOSHIDA
Naruto University of Education
Index
- MOMO and its derived versions
- How to develop Geant4 detector, physics list,
main program, and makefile, using MOMO
- GGE Geant4 Geometry Editor
- Characteristics
- Material Editor and Volume Editor
- Menus of GGE
- Material Editor
- Periodic Table of Elements
- Functionalities of the Material Editor
- The Logical Volume Editor
- Functionalities to define Geant4 logical volumes
- The Physical Volume Editor
- Limit of Physical volumes Editor
- Constructors of G4PVPlacement
- Single Positioned Volume
- Repeated Translationally Positioned Volumes
- Repeated Rotationally Positioned Volumes
- Replica in the X, Y or Z direction, Replica in rho, phi or Z direction
- Generation of C++ code
- Naming conventions in GGE
- Default values and combo-boxes
- GPE Geant4 Physics Editor
- Particle
- EM Processes
- C++ codes generated by GPE
- Persistent file
- MOMO's Companion Files
- Momomake.gmk generated by MOMO
- Main program generated by MOMO
- Makefiles and Environment Variables
- GAG and Gain
- GAG
- 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;
- "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.
- 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!
- 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.
-
The whole detector description can be saved in a persistent file and can
be loaded for later reuse.
-
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
- "material from scratch"
and
- "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;
- 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;
- 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.
- 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
- After selecting a solid tyle, user pushes the "append" or "insert" button
and a new row is created in the table.
- 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);
- 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. ));
- "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.
- Type 1 constructor = rotation of the frame, physical mother volume
- Type 2 constructor = rotation of a body, physical mother volume
- Type 3 constructor = rotation of the frame, logical mother volume
- 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.
- "box-bp" and "box-fp" in the first column to specify the pName, i.e., the name of the unstance of G4PVPlacement
- "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.
- "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.
- The first column specifies either body or frame rotation.
- The second column specifies the instance's name of the physical volume
- The third column specifies the name of the logical volume to be placed
- 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.
- The fifth column specifies the name of the mother volume, if it isn't NULL.
- 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
- 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.
- The first to 4-th columns are same as above.
- The columns 6, 7 and 8-th specify the position of the first copy
- The 10-th column specifies the direction of placement; X, Y or Z direction
- The 11-th column specifies the incremental step size of displacement
- 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.
- The columns "move", "pName", "pLogic", "MomType" and "pMother" are same as above.
- (X0, Y0, Z0) column specify the position of the center of an axial rotation
- "Radius" column specifies a radius of axially symmetric arrangement
- "RotAxis" column specifies the rotational axis ; X, Y or Z
- "Phi_0" and "dPhi" column specify a starting angle and incremental step angle
- 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
- width (in length or angle) and number of replicas
- offset (in length or angle)
- 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;
- G4Elements,
- G4Material,
- G4VisAttributes,
- G4Solids,
- G4LogicalVolume,
- Single Positioned Volumes,
- Repeated Volumes,
- Replicas
- 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.
- Elements and materials
- Elements are named "elementXXX", where XXX stands for the
element's symbol in the periodic table.
- materials are named just as you have typed in the second column
of the material window.
- 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".
- logical and physical volumes
- The strings of the pName (physical or logical) cells filled in the table are used literally as the names of instances.
- 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.
- In case of SPV (single positioned volume), the columns "pName" (instance of
physical volume) and "pLogical" may have the same strings.
-
In case of RVA (repeated volumes arrangement), "pName" is different from
"pLogical" whose copies are repeatedly placed.
- 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
- 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.
- 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.
- 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
-
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
-
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):
}
-
On a selection of a process, the default (predefined)
ordering parameters are given. The user can edit them as will.
-
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
- 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);
}
.....
.....
-
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);
}
}
}
- GPE generates a header file of user's physics list class.
-
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):
- 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.
- Click the GAG tab and open the GAG's pane
- Click the top left Geant menu and its "Start" button
- Choose the Geant4 binary file, using the file chooser and click on it
- 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.
- Click on the nodes or leaves make their help diaplayed. Commands in the opaque characters are inactive ones.
- Parameters are either chosen from the list or typed in.
- 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.
- 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.
- 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.
-
Gain is started on the Cygwin console. Gain can be started with
Java Web Start.
-
Top menu to connect to a server or close (kill) the running G4ant4 or finish Gain.
- The window to
choose SSh or Gain socket; now SSHINTERFACE is focused
- After typing in the remote host name,
SSH login window is shown.
-
When SSH login is accepted, Gain shows the
remore File Chooser. Geant4 with G4UIGAG interface can be started
from this chooser.
- When Geant4 is started,
Geant4 initialisation output are shown on the cygwin console.
- After the initialisation phase,
command tree window is available on Gain.
- 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.
-
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