Geant4 Users' Documents
Version: Geant4 7.0 December 2004
next_inactive up previous


Geant4 User's Guide - For Toolkit Developers


Contents

Introduction

Scope of this manual

The scope of this manual is to provide detailed information about the design of Geant4 classes. By understanding the design, you can extend the functionality of Geant4 provided by the original release of the toolkit.

This manual is for you if you are one of the following users:

  1. those who want to contribute to extend functionality to the Geant4 toolkit - for example, to add a new physics process, to add a new particle, etc,
  2. those who want to understand the detail of design of the toolkit.

We assume that you are already familiar with functionality of Geant4 toolkit which is explained in another user manual "User's Guide: For Application Developers". We assume that you have a practical knowledge of programming using C++. Although it is not mandatory, it will help if you have a knowledge of object-oriented analysis and design to understand this manual. If you are not familiar with this, we recommend to consult to several good introductory books.

How to use this manual

The manual starts with the complete reference to the user requirements document which was provided at the beginning of the development of the Geant4 toolkit. This document served as a base for the object-oriented analysis and design of the toolkit. By reading this document, you can understand the goal of the software design of Geant4.

The next chapter titled 'Object-oriented analysis and design of Geant4 classes' gives you detail information about the design of each class category and classes in it. If you want to add a new physics process to Geant4, it is mandatory that you understand the design of the physics processes category explained under this chapter.

Then the next chapter 'Guide to extend Geant4 class functionality' explains to you how to extend the functionality of Geant4 in more details. Although not all class categories are covered in this chapter, it is explained most ones which are important for most of users, for example, 'Event generator interface', 'Particles', 'Physics processes', etc.

You don't need to understand the whole content of this manual when you want to add a new functionality. For example, you want to add a new physics process, what you have to read and understand are:

  1. design principle described in the 'Physics processes' section of the chapter 'Object-oriented analysis and design of Geant4 classes',
  2. techniques explained in the 'Physics processes' section of the chapter 'Guide to extend Geant4 class functionality'.

Status of this chapter

User requirements document

Source of User Requirement Document

The Geant4 User Requirements Document follows the PSS-05 software engineering standards. A general description of the main capabilities and constrains is provided. The users are characterized in different categories depending on the level of interaction with the system. Also specific requirements are listed and classified.

You can obtain the document by clicking the following link: 

     http://cern.ch/geant4/OOAandD/URD.pdf

Object-oriented Analysis and Design of Geant4 Categories

Run and Event Categories

A discussion of the run and event managers and their relation to the tracking and stacking managers will be provided.

Booch diagrams for classes related to the event and event generator classes are shown in Figs. 1 and 2, respectively.

Figure 1: Event
\includegraphics[angle=270,scale=0.65]{OOAnalysisDesign/Event/classDgmEventManager.ps}

Figure 2: Event Generator
\includegraphics[angle=270,scale=0.65]{OOAnalysisDesign/EventGenerator/classDgmEventGen.ps}

Tracking

Design Philosophy

It is well known that the overall performance of a detector simulation depends critically on the CPU time spent propagating the particle through one step. The most important consideration in the object design of the tracking category is maintaining high execution speed in the GEANT4 simulation while utilizing the power of the object-oriented approach.

An extreme approach to the particle tracking design would be to integrate all functionalities required for the propagation of a particle into a single class. This design approach looks object-oriented because a particle in the real world propagates by itself while interacting with the material surrounding it. However, in terms of data hiding, which is one of the most important ingredients in the object-oriented approach, the design can be improved.

Combining all the necessary functionalities into a single class exposes all the data attributes to a large number of methods in the class. This is basically equivalent to using a common block in Fortran.

Instead of the 'big-class' approach, a hierarchical design was employed by GEANT4. The hierarchical approach, which includes inheritance and aggregation, enables large, complex software systems to be designed in a structured way. The simulation of a particle passing through matter is a complex task involving particles, detector geometry, physics interactions and hits in the detector. It is well-suited to the hierarchical approach. The hierarchical design manages the complexity of the tracking category by separating the system into layers. Each layer may then be designed independently of the others.

In order to maintain high-performance tracking, use of the inheritance ('is-a' relation) hierarchy in the tracking category was avoided as much as possible. For example, track and particle classes might have been designed so that a track 'is a' particle. In this scheme, however, whenever a track object is used, time is spent copying the data from the particle object into the track object. Adopting the aggregation ('has-a' relation) hierarchy requires only pointers to be copied, thus providing a performance advantage.

Class Design

Fig. (not yet available) shows a general overview of the tracking design in Unified Modelling Language Notation.

Tracking Algorithm

The key classes for tracking in GEANT4 are G4TrackingManager and G4SteppingManager. The singleton object "TrackingManager" from G4TrackingManager keeps all information related to a particular track, and it also manages all actions necessary to complete the tracking. The tracking proceeds by pushing a particle by a step, the length of which is defined by one of the active processes. The "TrackingManager" object delegates management of each of the steps to the "SteppingManager" object. This object keeps all information related to a particular step.

The public method ProcessOneTrack() in G4TrackingManager is the key to managing the tracking, while the public method Stepping() is the key to managing one step. The algorithms used in these methods are explained below.

ProcessOneTrack() in G4TrackingManager

  1. Actions before tracking the particle:
    Clear secondary particle vector
  2. Pre tracking user intervention process.
  3. Construct a trajectory if it is requested
  4. Give SteppingManager the pointer to the track which will be tracked
  5. Inform beginning of tracking to physics processes
  6. Track the particle Step-by-Step while it is alive
  7. Post tracking user intervention process.
  8. Destroy the trajectory if it was created

Stepping() in G4SteppingManager

  1. Initialize current step
  2. If particle is stopped, get the minimum life time from all the at rest processes and invoke InvokeAtRestDoItProcs for the selected AtRest processes
  3. If particle is not stopped:

Interaction with Physics Processes

The interaction of the tracking category with the physics processes is done in two ways. First each process can limit the step length through one of its three GetPhysicalInteractionLength() methods, AtRest, AlongStep, or PostStep. Second, for the selected processes the DoIt (AtRest, AlongStep or PostStep) methods are invoked. All this interaction is managed by the Stepping method of G4SteppingManager. To calculate the step length, the DefinePhysicalStepLength() method is called. The flow of this method is the following:

The method G4SteppingManager::InvokeAlongStepDoIts() is in charge of calling the AlongStepDoIt methods of the different processes:

The method G4SteppingManager::InvokePostStepDoIts is on charge of calling the PostStepDoIt methods of the different processes.

The method G4SteppingManager::InvokeAtRestDoIts is called instead of the three above methods in case the track status is fStopAndALive. It is on charge of selecting the rest process which has the shortest time before and then invoke it:

Ordering of Methods of Physics Processes

The ProcessManager of a particle is responsible for providing the correct ordering of process invocations. G4SteppingManager invokes the processes at each phase just following the order given by the ProcessManager of the corresponding particle.

For some processes the order is important. GEANT4 provides by default the right ordering. It is always possible for the user to choose the order of process invocations at the initial set up phase of GEANT4. This default ordering is the following:

  1. Ordering of GetPhysicalInteractionLength
  2. Ordering of DoIts

Status of Tracking section

created by ?
10.06.02 partially re-written by D.H. Wright
14.11.02 updated and partially re-written by P. Arce

Bibliography

1
Geant4 Users Guide for Application Developers.

Physics Processes

General

The object-oriented design of the generic physics process G4VProcess and its relation to the process manager is shown in Fig. 3. Fig. 4 shows how specific physics processes are related to G4VProcess.

Figure 3: Management of Physics Processes

Figure 4: General Physics Processes

Hit

The object-oriented design of the 'hit' related classes is shown in the following class diagrams. The diagrams are described in the Booch notation. Fig. 5 shows the general management of hit classes. Fig. 6 shows the OO design of user-related hit classes. Fig. 7 shows the OO design of the readout geometry.

Figure 5: Overview of hit classes management

Figure 6: User hit classes

Figure 7: Readout geometry
\includegraphics[angle=0,scale=0.6]{OOAnalysisDesign/Hit/classDgmReadoutGeom.ps}

Geometry

Fig. 8 shows a general overview, in UML notation, of the geometry design. A detailed collection of class diagrams from the geometry category is found in the Appendix.

\includegraphics[angle=0,scale=0.6]{OOAnalysisDesign/Geometry/overall.eps}
Figure 8: Overview of the geometry

Each physical volume represents a positioned logical volume, which in turn represents a leaf node or unpositioned subtree in the geometrical database. A logical volume may have from one to many daugther volumes.

Electromagnetic Fields

The object-oriented design of the classes related to the electromagnetic field is shown in the class diagram of Fig. 9. The diagram is described in UML notation.

Figure 9: Electromagnetic Field
\includegraphics[angle=0,scale=0.75]{OOAnalysisDesign/ElectromagneticField/field-prop.eps}

Particles

The object-oriented design of the 'particles' related classes is shown in the following class diagrams. The diagrams are described in the Booch notation. Fig. 10 shows a general overview of the particle classes. Fig. 11 shows classes related to the particle table. Fig. 12 shows the classes related to the particle decay table.

Figure 10: Particle classes

Figure 11: Particle Table

Figure 12: Particle Decay Table

Materials

The object-oriented design of the 'materials' related classes is shown in the class diagram: Fig. 13. The diagram is described in the Booch notation.

Figure 13: Materials
\includegraphics[angle=0,scale=0.7]{OOAnalysisDesign/Materials/classDgmMaterials.ps}

Global Usage

The "global" class category

The "global" category can be considered a place-holder for "general purpose" classes used by all categories defined in GEANT4. No back-dependencies to other GEANT4 categories affect the "global" domain.

Direct dependencies of "global" to external packages (CLHEP, STL, miscellaneous system utilities) are foreseen.

General purpose classes

The following set of classes defined in global/management can be considered as "general purpose" classes and are uncorrelated to each other: 
     G4Allocator 
     G4FastVector 
     G4PhysicsVector, G4LPhysicsFreeVector, G4PhysicsOrderedFreeVector 

     extract of the design class diagram from piim/processes/main 
         G4Timer 
         G4UserLimits
A general description of the major management classes in the "global" category is given in section 3.2 of the GEANT4 User's Guide for Application Developers.

The design

HEPRandom

The use of a static generator has been introduced in the original design of HEPRandom as a project requirement in GEANT4. In applications like GEANT4, where it is necessary to shoot random numbers (normally of the same engine) in many different methods and parts of the program, it is highly desirable not to have to rely-on/know global objects instantiated. By using static methods via a unique generator, randomness of a sequence of numbers is best assured.

Analysis and design of the HEPRandom module have been achieved following the Booch Object-Oriented methodology. Some of the original design diagrams in Booch notation are reported below. Fig. 14 is a general picture of the static class diagram.

Figure 14: HEPRandom module
\includegraphics[angle=0,scale=0.6]{OOAnalysisDesign/GlobalUsage/classDgmRandom.ps}

Fig. 15 is a dynamic object diagram illustrating the situation when a single random number is thrown by the static generator according to one of the available distributions. Only one engine is assumed to active at a time.

Figure 15: Shooting via the generator
\includegraphics[angle=0,scale=0.6]{OOAnalysisDesign/GlobalUsage/ObjDiagStat.ps}

Fig. 16 illustrates a random number being thrown by explicitly specifying an engine which can be shared by many distribution objects. The static interface is skipped here.

Figure 16: Shooting via distribution objects
\includegraphics[angle=0,scale=0.6]{OOAnalysisDesign/GlobalUsage/ObjDiagDist.ps}

Fig. 17 illustrates the situation when many generators are defined, each by a distribution and an engine. The static interface is skipped here.

Figure 17: Shooting with arbitrary engines
\includegraphics[angle=0,scale=0.6]{OOAnalysisDesign/GlobalUsage/ObjDiagEng.ps}

For detailed documentation about the HEPRandom classes see the CLHEP Reference Guide
(http://cern.ch/wwwasd/lhc++/clhep/manual/RefGuide/index.html)
or the CLHEP User Manual
(http://cern.ch/wwwasd/lhc++/clhep/manual/UserGuide/index.html).
Informations written in this manual are extracted from the original manifesto distributed with the HEPRandom package
(http://cern.ch/wwwasd/geant/geant4_public/Random.html).

HEPNumerics

The HEPNumerics module includes a set of classes which implement numerical algorithms for general use in GEANT4. Section 3.2.3 of the User's Guide for Application Developers contains a description of each class. Most of the algorithms were implemented using methods from the following books:

HEPGeometry

Documentation for the HEPGeometry module is provided in the CLHEP Reference Guide
(http://cern.ch/wwwasd/lhc++/clhep/manual/RefGuide/index.html) or the CLHEP User Manual
(http://cern.ch/wwwasd/lhc++/clhep/manual/UserGuide/index.html)

Status of this section

01.12.02 minor update by G. Cosmo

Visualization

Visualization Manager

The Visualization Manager is implemented by G4VisManager and its descendant class, say, MyVisManager, and it controls GEANT4 Visualization. Roles and structure of the Visualization Manager are described in Chapter 8 of the User's Guide for Application Developers.

Visualization drivers

GEANT4 has an abstract interface to an arbitrary graphics system. By defining a set of three C++ classes inheriting from the virtual base classes G4VGraphicsSystem, G4VSceneHandler, and G4VView, respectively, an arbitrary graphics system can easily be plugged in to GEANT4. The three classes are for (1) initialization of a graphics system, (2) modeling 3D scenes, and (3) rendering the modeled 3D scenes, respectively. The plugged-in graphics system is available for visualising detector simulation, i.e., visualization of simulated detector geometry, particle trajectories, hits, etc.

A set of the three concrete classes mentioned above is called a "visualization driver", For example, the DAWN-File driver, which is the interface to Fukui Renderer DAWN, is implemented by the following set of classes:

  1. G4DAWNFILE : public G4VGraphicsSystem
    for initialization
  2. G4DAWNFILESceneHandler : public G4VSceneHandler
    for modeling 3D scenes
  3. G4DAWNFILEView : public G4VView
    for rendering 3D scenes

Several visualization drivers are already prepared by default. They are all complementary to each other in many aspects. For details, see the User's Guides for Application Developers.

It is easy for a toolkit developer of GEANT4 to make a new graphics system connected to GEANT4. It is done by implementing a new set of three classes composing a new visualization driver.

Modeling sub-category

The sub-category visualization/modeling defines how to model a 3D scene for visualization. The term "3D scene" indicates a set of visualizable component objects put in a 3D world. A concrete class inheriting from the abstract base class G4VModel defines a "model", which describes how to visualize the corresponding component object belonging to a 3D scene. G4ModelingParameters defines various associated parameters.

For example, G4PhysicalVolumeModel knows how to visualize a physical volume. It describes a physical volume and its daughters to any desired depth. G4HitsModel knows how to visualize hits. G4TrajectoriesModel knows how to visualize trajectories. G4FlavoredParallelWorld knows how to visualize flavoured parallel world volumes.

The main task of a model is to describe itself to a 3D scene by giving a concrete implementation of the following virtual method of G4VModel: 

    virtual void DescribeYourselfTo (G4VGraphicsScene&) = 0;

The argument class G4VGraphicsScene is a minimal abstract interface of a 3D scene for the GEANT4 kernel defined in the graphics_reps category. Since G4VSceneHandler and its concrete descendants inherit from G4VGraphicsScene, the method DescribeYourselfTo() can pass information of a 3D scene to a visualization driver.

It is easy for a toolkit developer of GEANT4 to add a new kind of visualizable component object. It is done by implementing a new class inheriting from G4VModel.

View parameters

View parameters such as camera parameters, drawing styles (wireframe/surface etc) are held by G4ViewParameters. Each viewer holds a view parameters object which can be changed interactively and a default object (for use in the /vis/viewer/reset command).

If a toolkit developer of GEANT4 wants to add entries of view parameters, he should add fields and methods to G4ViewParameters.

User Interface

The object-oriented design of the 'user interface' related classes is shown in the class diagram Fig. 18. The diagram is described in the Booch notation.

Figure 18: Overview of user interface classes
\includegraphics[angle=270,scale=0.55]{OOAnalysisDesign/UserInterface/classDgmUserInterface.ps}

Guide to extend Geant4 class functionality

Geometry

What can be extended ?

GEANT4 already allows a user to describe any desired solid, and to use it in a detector description, in some cases, however, the user may want or need to extend GEANT4's geometry. One reason can be that some methods and types in the geometry are general and the user can utilise specialised knowledge about his or her geometry to gain a speedup. The most evident case where this can happen is when a particular type of solid is a key element for a specific detector geometry and an investment in improving its runtime performance may be worthwhile.

To extend the functionality of the Geometry in this way, a toolkit developer must write a small number of methods for the new solid. We will document below these methods and their specifications. Note that the implementation details for some methods are not a trivial matter: these methods must provide the functionality of finding whether a point is inside a solid, finding the intersection of a line with it, and finding the distance to the solid along any direction. However once the solid class has been created with all its specifications fulfilled, it can be used like any GEANT4 solid, as it implements the abstract interface of G4VSolid.

Other additions can also potentially be achieved. For example, an advanced user could add a new way of creating physical volumes. However, because each type of volume has a corresponding navigator helper, this would require to create a new Navigator as well. To do this the user would have to inherit from G4Navigator and modify the new Navigator to handle this type of volumes. This can certainly be done, but will probably be made easier to achieve in the future versions of the GEANT4 toolkit.

Adding a new type of Solid

We list below the required methods for integrating a new type of solid in GEANT4. Note that GEANT4's specifications for a solid pay significant attention to what happens at points that are within a small distance (tolerance, kCarTolerance in the code) of the surface. So special care must be taken to handle these cases in considering all different possible scenarios, in order to respect the specifications and allow the solid to be used correctly by the other components of the geometry module.

Creating a derived class of G4VSolid

The solid must inherit from G4VSolid or one of its derived classes and implement its virtual functions.

Mandatory member functions you must define are the following pure virtual of G4VSolid: 

 EInside Inside(const G4ThreeVector& p)
 G4double DistanceToIn(const G4ThreeVector& p)
 G4double DistanceToIn(const G4ThreeVector& p, const G4ThreeVector& v)
 G4ThreeVector SurfaceNormal(const G4ThreeVector& p)
 G4double DistanceToOut(const G4ThreeVector& p)
 G4double DistanceToOut(const G4ThreeVector& p, const G4ThreeVector& v,
                        const G4bool calcNorm=false,
                              G4bool *validNorm=0, G4ThreeVector *n)
 G4bool CalculateExtent(const EAxis pAxis,
                        const G4VoxelLimits& pVoxelLimit,
                        const G4AffineTransform& pTransform,
                              G4double& pMin,
                              G4double& pMax) const
 G4GeometryType GetEntityType() const
 std::ostream& StreamInfo(std::ostream& os) const
They must perform the following functions 

  EInside Inside(const G4ThreeVector& p)
This method must return: 

G4ThreeVector SurfaceNormal(const G4ThreeVector& p)
Return the outwards pointing unit normal of the shape for the surface closest to the point at offset p. 

G4double DistanceToIn(const G4ThreeVector& p)
Calculate distance to nearest surface of shape from an outside point p. The distance can be an underestimate. 

G4double DistanceToIn(const G4ThreeVector& p, const G4ThreeVector& v)
Return the distance along the normalised vector v to the shape, from the point at offset p. If there is no intersection, return kInfinity. The first intersection resulting from `leaving' a surface/volume is discarded. Hence, this is tolerant of points on surface of shape. 

G4double DistanceToOut(const G4ThreeVector& p)
Calculate distance to nearest surface of shape from an inside point. The distance can be an underestimate. 

G4double DistanceToOut(const G4ThreeVector& p, const G4ThreeVector& v,
                        const G4bool calcNorm=false,
                        G4bool *validNorm=0, G4ThreeVector *n=0);
Return distance along the normalised vector v to the shape, from a point at an offset p inside or on the surface of the shape. Intersections with surfaces, when the point is not greater than kCarTolerance/2 from a surface, must be ignored.

If calcNorm is true, then it must also set validNorm to either

If calcNorm is false, then validNorm and n are unused. 
G4bool CalculateExtent(const EAxis pAxis,
                        const G4VoxelLimits& pVoxelLimit,
                        const G4AffineTransform& pTransform,
                              G4double& pMin,
                              G4double& pMax) const
Calculate the minimum and maximum extent of the solid, when under the specified transform, and within the specified limits. If the solid is not intersected by the region, return false, else return true. 

G4GeometryType GetEntityType() const;
Provide identification of the class of an object (required for persistency and STEP interface). 

std::ostream& StreamInfo(std::ostream& os) const
Should dump the contents of the solid to an output stream.

The method: 

G4double GetCubicVolume()
should be implemented for every solid in order to cache the computed value (and therefore reuse it for future calls to the method) and to eventually implement a precise computation of the solid's volume. If the method will not be overloaded, the default implementation from the base class will be used (estimation through a Monte Carlo algorithm) and the computed value will not be stored.

There are a few member functions to be defined for the purpose of visualisation. The first method is mandatory, and the next four are not. 

  // Mandatory
  virtual void DescribeYourselfTo (G4VGraphicsScene& scene) const = 0;

  // Not mandatory
  virtual G4VisExtent GetExtent() const;
  virtual G4Polyhedron* CreatePolyhedron () const;
  virtual G4NURBS*      CreateNURBS      () const;
  virtual G4Polyhedron* GetPolyhedron    () const;
What these methods should do and how they should be implemented is described here. 

 void DescribeYourselfTo (G4VGraphicsScene& scene) const;
This method is required in order to identify the solid to the graphics scene. It is used for the purposes of ``double dispatch''. All implementations should be similar to the one for G4Box: 

void G4Box::DescribeYourselfTo (G4VGraphicsScene& scene) const
{
  scene.AddThis (*this);
}
The method: 

 G4VisExtent GetExtent() const;
provides extent (bounding box) as a possible hint to the graphics view. You must create it by finding a box that encloses your solid, and returning a VisExtent that is created from this. The G4VisExtent must presumably be given the minus x, plus x, minus y, plus y, minus z and plus z extents of this ``box''. For example a cylinder can say 

G4VisExtent G4Tubs::GetExtent() const
{
  // Define the sides of the box into which the G4Tubs instance would fit.
  return G4VisExtent (-fRMax, fRMax, -fRMax, fRMax, -fDz, fDz);
}
The method: 

 G4Polyhedron* CreatePolyhedron () const;
is required by the visualisation system, in order to create a realistic rendering of your solid. To create a G4Polyhedron for your solid, consult G4Polyhedron.

While the method: 

 G4Polyhedron* GetPolyhedron () const;
is a ``smart'' access function that creates on requests a polyhedron and stores it for future access and should be customised for every solid.

The method: 

 G4NURBS* CreateNURBS () const;
is not currently utilised, so you do not have to implement it.

Modifying the Navigator

For the vast majority of use-cases, it is not indeed necessary (and definitely not advised) to extend or modify the existing classes for navigation in the geometry. A possible use-case for which this may apply, is for the description of a new kind of physical volume to be integrated. We believe that our set of choices for creating physical volumes is varied enough for nearly all needs.
Future extensions of the GEANT4 toolkit will probably make easier exchanging or extending the G4Navigator, by introducing an abstraction level simplifying the customisation. At this time, a simple abstraction level of the navigator is provided by allowing overloading of the relevant functionalities.

Extending the Navigator

The main responsibilities of the Navigator are: The Navigator utilises one helper class for each type of physical volume that exists. You will have to reuse the helper classes provided in the base Navigator or create new ones for the new type of physical volume.

To extend G4Navigator you will have then to inherit from it and modify these functions in your ModifiedNavigator to request the answers for your new physical volume type from the new helper class. The ModifiedNavigator should delegate other cases to the GEANT4's standard Navigator.

Replacing the Navigator

Replacing the Navigator is another possible operation. It is similar to extending the Navigator, in that any types of physical volume that will be allowed must be handled by it. The same functionality is required as described in the previous section.

However the amount of work is probably potentially larger, if support for all the current types of physical volumes is required.

The Navigator utilises one helper class for each type of physical volume that exists. These could also potentially be replaced, allowing a simpler way to create a new navigation system.

Electromagnetic Fields

Creating a new type of Field

GEANT4 currently handles magnetic and electric fields and, in future releases, will handle combined electromagnetic fields. Fields due to other forces, not yet included in GEANT4, can be provided by describing the new field and the force it exerts on a particle passing through it. For the time being, all fields must be time-independent. This restriction may be lifted in the future.

In order to accommodate a new type of field, two classes must be created: a field type and a class that determines the force. The GEANT4 system must then be informed of the new field.

A new Field class

A new type of Field class may be created by inheriting from G4Field 
      class NewField : public G4Field
      {
         public: 
            void  GetFieldValue( const  double Point[3],
                                        double *pField )=0;
      }
and deciding how many components your field will have, and what each component represents. For example, three components are required to describe a vector field while only one component is required to describe a scalar field.

If you want your field to be a combination of different fields, you must choose your convention for which field goes first, which second etc. For example, to define an electromagnetic field we follow the convention that components 0,1 and 2 refer to the magnetic field and components 3, 4 and 5 refer to the electric field.

By leaving the GetFieldValue method pure virtual, you force those users who want to describe their field to create a class that implements it for their detector's instance of this field. So documenting what each component means is required, to give them the necessary information.

For example someone can describe DetectorAbc's field by creating a class DetectorAbcField, that derives from your NewField 

class DetectorAbcField : public NewField 
{
  public:
     void  MyFieldGradient::GetFieldValue( const double Point[3], 
                                           double *pField );
}

They then implement the function GetFieldValue 

      void  MyFieldGradient::GetFieldValue( const  double Point[3],
                                            double *pField )
      {
         // We expect pField to point to pField[9]; 
         // This & the order of the components of pField is your own 
         // convention
       
         // We calculate the value of pField at Point ...
      }

A new Equation of Motion for the new Field

Once you have created a new type of field, you must create an Equation of Motion for this Field. This is required in order to obtain the force that a particle feels.

To do this you must inherit from G4Mag_EqRhs and create your own equation of motion that understands your field. In it you must implement the virtual function EvaluateRhsGivenB. Given the value of the field, this function calculates the value of the generalised force. This is the only function that a subclass must define. 

     virtual void EvaluateRhsGivenB( const  G4double y[],
                              const  G4double B[3],
                                     G4double dydx[] ) const = 0;

In particular, the derivative vector dydx is a vector with six components. The first three are the derivative of the position with respect to the curve length. Thus they should set equal to the normalised velocity, which is components 3, 4 and 5 of y. 

  (dydx[0], dydx[1], dydx[2]) = (y[3], y[4], y[5])

The next three components are the derivatives of the velocity vector with respect to the path length. So you should write the "force" components for 

      dydx[3], dydx[4] and dydx[5]

for your field.

Get a G4FieldManager to use your field

In order to inform the GEANT4 system that you want it to use your field as the global field, you must do the following steps:

  1. Create a Stepper of your choice: 
           
      yourStepper = new G4ClassicalRK( yourEquationOfMotion );
                // or if your field is not smooth eg
                //     new G4ImplicitEuler( yourEquationOfMotion );
  2. Create a chord finder that uses your Field and Stepper. You must also give it a minimum step size, below which it does not make sense to attempt to integrate: 
          yourChordFinder= new G4ChordFinder( yourField,
                                 yourMininumStep, // say 0.01*mm
                                 yourStepper );
  3. Next create a G4FieldManager and give it that chord finder, 
          yourFieldManager= new G4FieldManager();
      yourFieldManager.SetChordFinder(yourChordFinder);
  4. Finally we tell the Geometry that this FieldManager is responsible for creating a field for the detector. 
          G4TransportationManager::GetTransportationManager()
                            -> SetFieldManager( yourFieldManager );

Changes for non-electromagnetic fields

If the field you are interested in simulating is not electromagnetic, another minor modification may be required. The transportation currently chooses whether to propagate a particle in a field or rectilinearly based on whether the particle is charged or not. If your field affects non-charged particles, you must inherit from the G4Transportation and re-implement the part of GetAlongStepPhysicalInteractionLength that decides whether the particles is affected by your force.

In particular the relevant section of code does the following: 

    //  Does the particle have an (EM) field force exerting upon it?
  //
  if( (particleCharge!=0.0) ){
     
     fieldExertsForce= this->DoesGlobalFieldExist();
     // Future: will/can also check whether current volume's field is Zero or
     //  set by the user (in the logical volume) to be zero.
  }
and you want it to ask whether it feels your force. If, for the sake of an example, you wanted to see the effects of gravity on a heavy hypothetical particle, you could say 

  
  //  Does the particle have my field's force exerted on it?
  //
  if (particle->GetName() == "VeryHeavyWIMP") {
     fieldExertsForce= this->DoesGlobalFieldExist();  // For gravity
  }

After doing all these steps, you will be able to see the effects of your force on a particle's motion.

Status of the section

10.06.02 partially re-written by D.H. Wright
14.11.02 spell check by P. Arce

Physics Processes

Adding a new electromagnetic process.

Adding a new hadronic process.

Extending hadronic physics functionality

Introduction

Optimal exploitation of hadronic final states played a key role in successes of all recent collider experiment in HEP, and the ability to use hadronic final states will continue to be one of the decisive issues during the analysis phase of the LHC experiments. Monte Carlo programs like GEANT4[] facilitate the use of hadronic final states, and have been developed for many years.

We give an overview of the Object Oriented frameworks for hadronic generators in GEANT4, and illustrate the physics models underlying hadronic shower simulation on examples, including the three basic types of modeling; data driven, parametrisation driven, and theory driven modeling, and their possible realisations in the Object Oriented component system of GEANT4. We put particular focus on the level of extendibility that can and has been achieved by our Russian dolls approach to Object Oriented design, and the role and importance of the frameworks in a component system.

Principal considerations

The purpose of this section is to explain the implementation frameworks used in and provided by GEANT4 for hadronic shower simulation as in the 1.1 release of the program. The implementation frameworks follow the Russian dolls approach to implementation framework design. A top-level, very abstracting implementation framework provides the basic interface to the other GEANT4 categories, and fulfils the most general use-case for hadronic shower simulation. It is refined for more specific use-cases by implementing a hierarchy of implementation frameworks, each level implementing the common logic of a particular use-case package in a concrete implementation of the interface specification of one framework level above, this way refining the granularity of abstraction and delegation. This defines the Russian dolls architectural pattern. Abstract classes are used as the delegation mechanism2. All framework functional requirements were obtained through use-case analysis. In the following we present for each framework level the compressed use-cases, requirements, designs including the flexibility provided, and illustrate the framework functionality with examples. All design patterns cited are to be read as defined in [2].

Level 1 Framework - processes

There are two principal use-cases of the level 1 framework. A user will want to choose the processes used for his particular simulation run, and a physicist will want to write code for processes of his own and use these together with the rest of the system in a seamless manner.

Requirements

  1. Provide a standard interface to be used by process implementations.
  2. Provide registration mechanisms for processes.

Design and interfaces

Both requirements are implemented in a sub-set of the tracking-physics interface in GEANT4. The class diagram is shown in figure 19.

Figure 19: Level 1 implementation framework of the hadronic category of GEANT4.
\includegraphics[width=14cm]{GuideToExtendFunctionality/HadronicPhysics/Level1.eps}

All processes have a common base-class G4VProcess, from which a set of specialised classes are derived. Three of them are used as base classes for hadronic processes for particles at rest (G4VRestProcess), for interactions in flight (G4VDiscreteProcess), and for processes like radioactive decay where the same implementation can represent both these extreme cases (G4VRestDiscreteProcess).

Each of these classes declares two types of methods; one for calculating the time to interaction or the physical interaction length, allowing tracking to request the information necessary to decide on the process responsible for final state production, and one to compute the final state. These are pure virtual methods, and have to be implemented in each individual derived class, as enforced by the compiler.

Framework functionality

The functionality provided is through the use of process base-class pointers in the tracking-physics interface, and the G4ProcessManager. All functionality is implemented in abstract, and registration of derived process classes with the G4ProcessManager of an individual particle allows for arbitrary combination of both GEANT4 provided processes, and user-implemented processes. This registration mechanism is a modification on a Chain of Responsibility. It is outside the scope of the current paper, and its description is available from [3].

Level 2 Framework - Cross-sections and Models

At the next level of abstraction, only processes that occur for particles in flight are considered. For these, it is easily observed that the sources of cross-sections and final state production are rarely the same. Also, different sources will come with different restrictions. The principal use-cases of the framework are addressing these commonalities. A user might want to combine different cross-sections and final state or isotope production models as provided by GEANT4, and a physicist might want to implement his own model for particular situation, and add cross-section data sets that are relevant for his particular analysis to the system in a seamless manner.

Requirements

  1. Flexible choice of inclusive scattering cross-sections.
  2. Ability to use different data-sets for different parts of the simulation, depending on the conditions at the point of interaction.
  3. Ability to add user-defined data-sets in a seamless manner.
  4. Flexible, unconstrained choice of final state production models.
  5. Ability to use different final state production codes for different parts of the simulation, depending on the conditions at the point of interaction.
  6. Ability to add user-defined final state production models in a seamless manner.
  7. Flexible choice of isotope production models, to run in parasitic mode to any kind of transport models.
  8. Ability to use different isotope production codes for different parts of the simulation, depending on the conditions at the point of interaction.
  9. Ability to add user-defined isotope production models in a seamless manner.

Design and interfaces

The above requirements are implemented in three framework components, one for cross-sections, final state production, and isotope production each. The class diagrams are shown in figure 20 for the cross-section aspects, figure 21 for the final state production aspects, and figure 22 for the isotope production aspects.

Figure 20: Level 2 implementation framework of the hadronic category of GEANT4; cross-section aspect.
\includegraphics[width=14cm]{GuideToExtendFunctionality/HadronicPhysics/Level2_1.eps}

Figure 21: Level 2 implementation framework of the hadronic category of GEANT4; final state production aspect.
\includegraphics[width=14cm]{GuideToExtendFunctionality/HadronicPhysics/Level2_2.eps}

Figure 22: Level 2 implementation framework of the hadronic category of GEANT4; isotope production aspect
\includegraphics[width=14cm]{GuideToExtendFunctionality/HadronicPhysics/Level2_3.eps}

The three parts are integrated in the G4HadronicProcess class, that serves as base-class for all hadronic processes of particles in flight.

Cross-sections

Each hadronic process is derived from G4HadronicProcess, which holds a list of ``cross section data sets''. The term ``data set'' is representing an object that encapsulates methods and data for calculating total cross sections for a given process in a certain range of validity. The implementations may take any form. It can be a simple equation as well as sophisticated parameterisations, or evaluated data. All cross section data set classes are derived from the abstract class G4VCrossSectionDataSet, which declares methods that allow the process inquire, about the applicability of an individual data-set through IsApplicable(const G4DynamicParticle*, const G4Element*), and to delegate the calculation of the actual cross-section value through
GetCrossSection(const G4DynamicParticle*, const G4Element*).

Final state production

For final state production, we provide the G4HadronicInteraction base class. It declares a minimal interface of only one pure virtual method for final state production,
G4VParticleChange* ApplyYourself(const G4Track &, G4Nucleus &).
G4HadronicProcess provides a registry for final state production models inheriting from G4HadronicInteraction. Again, final state production model is meant in very general terms. This can be an implementation of a quark gluon string model[4], a sampling code for ENDF/B data formats[5], or a parametrisation describing only neutron elastic scattering off Silicon up to 300 MeV.

Isotope production

For isotope production, a base class (G4VIsotopeProduction) is provided. It declares a method (G4IsoResult * GetIsotope(const G4Track &, const G4Nucleus &)) that calculates and returns the isotope production information. Any concrete isotope production model will inherit from this class, and implement the method. Again, the modeling possibilities are not limited, and the implementation of concrete production models is not restricted in any way. By convention, the GetIsotope method returns NULL, if the model is not applicable for the current projectile target combination.

Framework functionality:

Cross-sections

G4HadronicProcess provides registering possibilities for data-sets. A default is provided covering all possible conditions to some approximation. The process stores and retrieves the data-sets through a data-store that acts like a FILO stack (a Chain of Responsibility with a First In Last Out decision strategy). This allows the user to map out the entire parameter space by overlaying cross-section data-sets to optimise the overall result. An example are the cross-sections for low energy neutron transport. If these are registered last by the user, they will be used whenever low energy neutrons are encountered. In all other conditions the system falls back on the default, or data sets with earlier registration dates. The fact that the registration is done through abstract base classes with no side-effects allows the user to implement and use his own cross-sections. An example are special reaction cross-sections of $K^0$-nuclear interactions that might be used for $\epsilon/\epsilon '$ analysis at LHC to control the systematic error.

Final state production

The G4HadronicProcess provides a registration service for classes deriving from G4HadronicInteraction, and delegates final state production to the applicable model. G4HadronicInteraction provides the functionality needed to define and enforce the applicability of a particular model. Models inheriting from G4HadronicInteraction can be restricted in applicability in projectile type and energy, and can be activated/deactivated for individual materials and elements. This allows a user to use final state production models in arbitrary combinations, and to write his own models for final state production. The design is a variant of a Chain of Responsibility. An example would be the likely CMS scenario - the combination of low energy neutron transport with a quantum molecular dynamics[6] or chiral invariant phase space decay[7] model in the case of tracker materials and fast parametrised models for calorimeter materials, with user defined modeling of interactions of spallation nucleons with the most abundant tracker and calorimeter materials.

Isotope production

The G4HadronicProcess by default calculates the isotope production information from the final state given by the transport model. In addition, it provides a registering mechanism for isotope production models that run in parasitic mode to the transport models and inherit from G4VIsotopeProduction. The registering mechanism behaves like a FILO stack, again based on Chain of Responsibility. The models will be asked for isotope production information in inverse order of registration. The first model that returns a non-NULL value will be applied. In addition, the G4HadronicProcess provides the basic infrastructure for accessing and steering of isotope-production information. It allows to enable and disable the calculation of isotope production information globally, or for individual processes, and to retrieve the isotope production information through the
G4IsoParticleChange * GetIsotopeProductionInfo() method at the end of each step. The G4HadronicProcess is a finite state machine that will ensure the GetIsotopeProductionInfo returns a non-zero value only at the first call after isotope production occurred. An example of the use of this functionality is the study of activation of a Germanium detector in a high precision, low background experiment.

Level 3 Framework - Theoretical Models

Figure 23: Level 3 implementation framework of the hadronic category of GEANT4; theoretical model aspect.
\includegraphics[width=14cm]{GuideToExtendFunctionality/HadronicPhysics/Level3_1.eps}
GEANT4 provides at present one implementation framework for theory driven models. The main use-case is that of a user wishing to use theoretical models in general, and to use various intra-nuclear transport or pre-compound models together with models simulating the initial interactions at very high energies.

Requirements

  1. Allow to use or adapt any string-parton or parton transport[8] model.
  2. Allow to adapt event generators, ex. PYTHIA[9] for final state production in shower simulation.
  3. Allow for combination of the above with any intra-nuclear transport (INT).
  4. Allow stand-alone use of intra-nuclear transport.
  5. Allow for combination of the above with any pre-compound model.
  6. Allow stand-alone use of any pre-compound model.
  7. Allow for use of any evaporation code.
  8. Allow for seamless integration of user defined components for any of the above.

Design and interfaces

To provide the above flexibility, the following abstract base classes have been implemented: In addition, the class G4TheoFSGenerator is provided to orchestrate interactions between these classes. The class diagram is shown in figure 23.

G4VHighEnergyGenerator serves as base class for parton transport or parton string models, and for Adapters to event generators. This class declares two methods, Scatter, and GetWoundedNucleus.

The base class for INT inherits from G4HadronicInteraction, making any concrete implementation usable as stand-alone model. In doing so, it re-declares the ApplyYourself interface of G4HadronicInteraction, and adds a second interface, Propagate, for further propagation after high energy interactions. Propagate takes as arguments a three-dimensions model of a wounded nucleus, and a set of secondaries with energies and positions.

The base class for pre-equilibrium decay models, G4VPreCompoundModel, inherits from G4HadronicInteraction, again making any concrete implementation usable as stand-alone model. It adds a pure virtual DeExcite method for further evolution of the system when intra-nuclear transport assumptions break down. DeExcite takes a G4Fragment, the GEANT4 representation of an excited nucleus, as argument.

The base class for evaporation phases, G4VExcitationHandler, declares an abstract method, BreakItUP(), for compound decay.

Framework functionality

G4TheoFSGenerator inherits from G4HadronicInteraction, and hence can be registered as model for final state production with a hadronic process. It allows to register a concrete implementation of G4VIntranuclearTransportModel and G4VHighEnergyGenerator, and delegates initial interactions, and intra-nuclear transport of the corresponding secondaries to the respective classes. The design is a complex variant of a Strategy. The most spectacular application of this pattern is the use of parton-string models for string excitation, quark molecular dynamics for correlated string decay, and quantum molecular dynamics for transport, a combination which promises to result in a coherent description of quark gluon plasma in high energy nucleus nucleus interactions.

G4VIntranuclearTransportModel provides registering mechanisms for concrete implementations of G4VPreCompoundModel, and provides concrete intra-nuclear transports with the possibility to delegate pre-compound decay to these models.

G4VPreCompoundModel provides a registering mechanism for compound decay through the G4VExcitationHandler interface, and provides concrete implementations with the possibility to delegate the decay of a compound nucleus.

The concrete scenario of G4TheoFSGenerator using a dual parton model and a classical cascade, which in turn uses an exciton pre-compound model that delegates to an evaporation phase, would be the following: G4TheoFSGenerator receives the conditions of the interaction; a primary particle and a nucleus. It asks the dual parton model to perform the initial scatterings, and return the final state, along with the by then damaged nucleus. The nucleus records all information on the damage sustained. G4TheoFSGenerator forwards all information to the classical cascade, that propagates the particles in the already damaged nucleus, keeping track of interactions, further damage to the nucleus, etc.. Once the cascade assumptions break down, the cascade will collect the information of the current state of the hadronic system, like excitation energy and number of excited particles, and interpret it as a pre-compound system. It delegates the decay of this to the exciton model. The exciton model will take the information provided, and calculate transitions and emissions, until the number of excitons in the system equals the mean number of excitons expected in equilibrium for the current excitation energy. Then it hands over to the evaporation phase. The evaporation phase decays the residual nucleus, and the Chain of Command rolls back to G4TheoFSGenerator, accumulating the information produced in the various levels of delegation.

Level 4 Frameworks - String Parton Models and Intra-Nuclear Cascade

Figure 24: Level 4 implementation framework of the hadronic category of GEANT4; parton string aspect.
\includegraphics[width=14cm]{GuideToExtendFunctionality/HadronicPhysics/Level4_1.eps}

Figure 25: Level 4 implementation framework of the hadronic category of GEANT4; intra-nuclear transport aspect.
\includegraphics[width=14cm]{GuideToExtendFunctionality/HadronicPhysics/Level4_2.eps}
The use-cases of this level are related to commonalities and detailed choices in string-parton models and cascade models. They are use-cases of an expert user wishing to alter details of a model, or a theoretical physicist, wishing to study details of a particular model.

Requirements

  1. Allow to select string decay algorithm
  2. Allow to select string excitation.
  3. Allow to select concrete implementation of three-dimensional model of the nucleus
  4. Allow to select concrete implementation of final state and cross-sections in intra-nuclear scattering.

Design and interfaces

To fulfil the requirements on string models, two abstract classes are provided, the G4VPartonStringModel and the G4VStringFragmentation. The base class for parton string models, G4VPartonStringModel, declares the GetStrings() pure virtual method. G4VStringFragmentation, the pure abstract base class for string fragmentation, declares the interface for string fragmentation.

To fulfil the requirements on intra-nuclear transport, two abstract classes are provided, G4V3DNucleus, and G4VScatterer. At this point in time, the usage of these intra-nuclear transport related classes by concrete codes is not enforced by designs, as the details of the cascade loop are still model dependent, and more experience has to be gathered to achieve standardisation. It is within the responsibility of the implementers of concrete intra-nuclear transport codes to use the abstract interfaces as defined in these classes.

The class diagram is shown in figure 24 for the string parton model aspects, and in figure 25 for the intra-nuclear transport.

Framework functionality

Again variants of Strategy, Bridge and Chain of Responsibility are used. G4VPartonStringModel implements the initialisation of a three-dimensional model of a nucleus, and the logic of scattering. It delegates secondary production to string fragmentation through a G4VStringFragmentation pointer. It provides a registering service for the concrete string fragmentation, and delegates the string excitation to derived classes. Selection of string excitation is through selection of derived class. Selection of string fragmentation is through registration.

Level 5 Framework - String De-excitation

Figure 26: Level 5 implementation framework of the hadronic category of GEANT4; string fragmentation aspect.
\includegraphics[width=14cm]{GuideToExtendFunctionality/HadronicPhysics/Level5_1.eps}
The use-case of this level is that of a user or theoretical physicist wishing to understand the systematic effects involved in combining various fragmentation functions with individual types of string fragmentation. Note that this framework level is meeting the current state of the art, making extensions and changes of interfaces in subsequent releases likely.

Requirements

  1. Allow the selection of fragmentation function.

Design and interfaces

A base class for fragmentation functions, G4VFragmentationFunction, is provided. It declaring the GetLightConeZ() interface.

Framework functionality

The design is a basic Strategy. The class diagram is shown in figure 26. At this point in time, the usage of the G4VFragmentationFunction is not enforced by design, but made available from the G4VStringFragmentation to an implementer of a concrete string decay. G4VStringFragmentation provides a registering mechanism for the concrete fragmentation function. It delegates the calculation of $z_f$ of the hadron to split of the string to the concrete implementation. Standardisation in this area is expected.

Bibliography

1
The GEANT 4 Collaboration,
CERN/DRDC/94-29, DRDC/P58 1994.

2
E. Gamm et al., Design Patterns, Addison-Wesley Professional Computing Series, 1995.

3
http://cern.ch/wwwasd/geant4/G4UsersDocuments/Overview/html/index.html

4
Kaidalov A. B., Ter-Martirosyan K. A., Phys. Lett. B117 247 (1982);

5
Data Formats and Procedures for the Evaluated Nuclear Data File, National Nuclear Data Center, Brookhave National Laboratory, Upton, NY, USA.

6
For example: VUU and (R)QMD model of high-energy heavy ion collisions. H. Stocker et al., Nucl. Phys. A538, 53c-64c (1992)

7
P.V. Degtyarenko, M.V. Kossov, H.P. Wellisch, Eur. Phys J. A 8, 217-222 (2000)

8
VNI 3.1, Klaus Geiger (Brookhaven), BNL-63762, Comput. Phys. Commun. 104, 70-160 (1997)

9
M. Bertini, L. Lönnblad, T. Sjörstrand, Pythia version 7-0.0 - a proof-of-concept version, LU-TP 00-23, hep-ph/0006152, May 2000

Visualization

The following sections contain various information for extending class functionalities of GEANT4 visualization:

Appendix

Class Diagrams for the Geometry Category

Figure 27 shows the OO design of the logical volume. Figure 28 shows the OO design of the physical volume. Figure 29 shows the OO design of the CSG solids. Figure 30 shows the OO design of the boolean solids. Figure 31 shows the OO design of the specific solids. Figure 32 shows the OO design of the BREP solids. Figure 33 shows the OO design of the BREP curves. Figure 34 shows the OO design of the BREP surfaces. Figure 35 shows the OO design for reflections of solids. Figure 36 shows the OO design of the touchables. Figure 37 shows the OO design of reference counting of touchables. Figure 38 shows the OO design of smart voxels. Figure 39 shows the OO design of the navigator. Figure 40 shows the OO design of detector regions.

Figure 27: Logical volumes
\includegraphics[angle=0,scale=0.8]{OOAnalysisDesign/Geometry/logical_volumes.eps}

Figure 28: Physical volumes
\includegraphics[angle=0,scale=0.75]{OOAnalysisDesign/Geometry/physical_volumes.eps}

Figure 29: CSG solids
\includegraphics[angle=0,scale=0.7]{OOAnalysisDesign/Geometry/csg_solids.eps}

Figure 30: Boolean solids
\includegraphics[angle=0,scale=0.75]{OOAnalysisDesign/Geometry/boolean_solids.eps}

Figure 31: Specific solids
\includegraphics[angle=0,scale=0.75]{OOAnalysisDesign/Geometry/specific_solids.eps}

Figure 32: BREP solids
\includegraphics[angle=0,scale=0.65]{OOAnalysisDesign/Geometry/breps_solids.eps}

Figure 33: BREP curves
\includegraphics[angle=0,scale=0.6]{OOAnalysisDesign/Geometry/breps_curves.eps}

Figure 34: BREP surfaces
\includegraphics[angle=0,scale=0.65]{OOAnalysisDesign/Geometry/breps_surfaces.eps}

Figure 35: Reflections of solids
\includegraphics[angle=0,scale=0.75]{OOAnalysisDesign/Geometry/reflections.eps}

Figure 36: Touchables
\includegraphics[angle=0,scale=0.65]{OOAnalysisDesign/Geometry/touchables.eps}

Figure 37: Reference counting for touchables
\includegraphics[angle=0,scale=0.75]{OOAnalysisDesign/Geometry/refcount-touch.eps}

Figure 38: Smart Voxels
\includegraphics[angle=0,scale=0.75]{OOAnalysisDesign/Geometry/smart_voxels.eps}

Figure 39: Navigator
\includegraphics[angle=0,scale=0.65]{OOAnalysisDesign/Geometry/navigator.eps}

Figure 40: Regions
\includegraphics[angle=0,scale=0.65]{OOAnalysisDesign/Geometry/regions.eps}

About this document ...

Geant4 User's Guide - For Toolkit Developers

This document was generated using the LaTeX2HTML translator Version 2002-2-1 (1.70)

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The command line arguments were:
latex2html -local_icons -split 3 toolkitDeveloper.tex

The translation was initiated by on 2004-12-06

next_inactive up previous
2004-12-06