Home

Geant4 User`s Guide - For Toolkit Developers

1. IsApplicable lt GetCrossSection lt lt Concrete gt gt BDataSet Figure 20 Level 2 implementation framework of the hadronic category of GEANT cross section aspect 46 methods that allow the process inquire about the applicability of an individ ual 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 amp G4Nucleus 4 G4HadronicProcess provides a registry for final state production models in heriting from G4HadronicInteraction Again final state production model is meant in very general terms This can be an implementation of a quark gluon string model a sampling code for ENDF B data formats 5 or a parametrisation describing only neutron elastic scattering off Silicon up to 300 MeV lt lt Abstract gt gt G4HadronicProcess lt lt virtual gt gt GetMicroscopicCrossSection amp lt lt virtual gt gt PostStepDolt RegisterMe ChooseHadronicinteraction GeneralPostStepDolt lt lt static gt gt GetlsotopeProductionInfo
2. PST e M PS VE theParticleTable D hePreAssigneiDecayProducts theDecayTable m po theMoment mbirection 0 1 Js 7 M do PEN H G4ParticleTable 1 PL A lt G4DecayProducts G4DecayTable 1 i y PushProducts Ed Fa Ra lt Momentum SetParentParticle dre Saa 7x _ H MS Boost x 3 ue Figure 10 Particle classes 24 GPariceTable G Particle Messenger entries setNewValue findParticle d getCurrentValue findAntiParticle ee 1 ES insert PX GetParticleTable 2 fel od 3 p CN e A E flteyator Dictionary Na 1 G4Strin x il st Leadon Fosa cdi IN atin G4PTbleDi G4Particle mim lond Benton d lt narylterator BS y S i YAD x xt H i presse ES a PANE j j j pe j BK lt Naw KV y KP VP 2X4 ges Mem I Fou e i i pg RWTValHa K RWTEYSIIS y shDictionar tDictionary fi A poe rom RWTools from RWTools AREN Figure 11 Particle Table 5 G4DecayTable S FR pre Sac SS P SelectADecayChannel G4Dynamic G Lorentz lt Particle Rotation Ses Parente mes n Ri from Global
3. G4PVReplica c4PvRep 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 21 3 6 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 G4TransportationManager from navigation S const GetFieldManager ___z lt lt const gt gt GetNavigatorFo G4Transportation lt lt const gt gt GetPropagadtorEL from processes lt lt static gt gt GetTransporta 1 G4Navigator from navigation G4FieldManager createChordFinder 0 7 DoesFieldExist GetDetectorField fN vigator I fChordFinder 0 G4ChordFinder AdvanceChordLimited GetDeltaChord GetIntegrationDriver SetDeltaChord set IntegrationDriver Figure 9 Electromagnetic Field 22 3 7 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 cl
4. 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 T 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 45 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 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 G4Ha
5. gt gt lt lt virtual gt gt ComputeDimensi lt lt virtual gt gt DistanceToIn S virtual DistanceToOut lt lt const gt gt GetName lt lt virtual gt gt Inside A G4VCSGfaceted faces G4VCSGface Figure 31 Specific solids 62 G4Assembly lt lt const gt gt GetNumbe lt lt const gt gt GetPlacedSolid BORGO see 1 amp N N placedVec Es N G4PlacedSolid S const GetRotation lt lt const gt gt GetSolid lt lt const gt gt GetTranslati G4IntersectionSolid from Geometry Bool Figure 32 BREP solids 63 orliginal parameters PConeParameters original parameters PGonParameters G4CurveRayIntersection GetDistance GetPoint GetRay G4CurveVectol JlastInten ection segments 1 Es T gt G4CompositeCurve kis M how cetSegments s G4Conic we Geteshi ft Sa GetPasition i G4CurvePoint GetCurve GetPoint Reset Figure 33 BREP curves 64 GASTEPEntity G4SurfaceBoundary E Bi s surfaceBoundary splitWithCylind i 1 SplitW
6. PA ector pM from BaseClass n Y cad J p A T LS L generators Ne amp aed 3 y Pag DE R N DE ue pre gt ut a 1 d ae j N G4PrimaryVertex GaDynamic arig e y generatePrimaryVertex bont GAThreeVecior Vertex G4PrimaryVertex Point G4ThreeVector 1 from PhysicsProcess particles L insert vertex e Es er A po NER j G4UserPrimaryGen gt en Y erator 1 P i ATA TC up XT V lt Tees N E i I ANSA oe E x Rem bm amp id N Ss PER 4 gt i d Pu ND BT N D SA G4ParticleDefinition gt G4DynamicPartici G4ParticleGun from ParticleDefinition from ParticleDefinition d set particlg_defniHion EU o f sel_particle_energy BT 1 Hag set particle momentum j SN set particle position pm y E w 1 E d Ac P d M gt ESE A A x X e Pd File users kurasige ROSE2 940831 mdl Thu Aug 31 19 58 30 1995 Class Diagram EventGenerator Main Figure 2 Event Generator 3 2 Tracking 3 2 1 Design Philosophy It is well known that the overall performance of a detector simulation de pends critically on the CPU time spent propagating the particle through one step The most important consideration in the object design of the track ing category is maintaining high execution speed in the GEANT4
7. 4 Gavi ealorimeterti er ted draw tsCollection eu M j pin O GAS e moze i d a calorimeter NOM gt calorimeterHi gt EN fUv Sa f i TN chamberHitsCollect gt P 3 E E fection d onArray Choice out of these two pue kinds of vectors G4Allocator WTPtrOrderedVe _ from Globals an ctor counter counterHitsCollection from RogueWave counterHitsCollectio gt nArray Figure 6 User hit classes 19 GAVSensitiveDe a tector 7 T NR _ GAVReadOutG gt eometry o includetist bul incl ist eW A Eee UN IP excl X gt aa A AA N G4GRSVolume gt G4SensitiveVol N from Geometry i umelist Niin ea i CheckLV an a N g ca check __ G4GRSSoid T GAVPhysical d n from Geometry Ne lt Volume I from Geometry N ym Wer gt So c TS G4LogicalVol gt G4VTouchable ume from Geometry from Geometry wW p Figure 7 Readout geometry 20 G4GeometryManager G4SolidStore 3 closeGeomet ry lt lt static gt gt DeRegister lt lt static gt gt Get Instance lt lt static gt gt Get Instance openGeomet ry lt lt static gt gt Register Buildoptimisations G4PhysicalVolumeSto
8. 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 4 5 Visualization The following sections contain various information for extending class func tionalities of GEANT4 visualization e User s Guide for Application Developers Chapter 8 Visualization e User s Guide for Toolkit Developers Chapter 3 Object oriented Anal ysis and Design of GEANT4 Classes Section 9 Visualization 56 5 Appendix 5 1 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 re
9. for interac tions in flight G4VDiscreteProcess and for processes like radioactive de cay where the same implementation can represent both these extreme cases GAVRestDiscreteProcess 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 GAProcessManager All functionality is implemented in abstract and registration of derived pro Purely Abstract G4VProcess S PostStepGetPhysicallnteractionLength PostStepDolt Y AlongStepGetPhysicallnteractionLength AlongStepDolt AtRestGetPhysicalInteractionLength AtRestDolt lt lt Abstract gt gt lt lt Abstract gt gt G4VDiscreteProcess G4VRestProcess PostStepGetPhysicallnteractionLength AtRestGetPhysicallnteractionLength PostStepDolt AtRestDolt lt lt Abstract gt gt G4HadronicProcess lt lt virtual gt gt GetMicroscopicCrossSection amp lt lt virtual gt gt PostStepDolt S Registe
10. 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 GAVPartonStringModel and the GAVStringFragmentation The base class for parton string models G4VPartonStringModel declares the GetStrings O 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 de pendent 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 as pects 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 initial isation of a three dimensional mod
11. AlongStepGetPhysicalInteractionLength method of all active pro cesses is called Each process returns a step length and the minimum of these and the This method also returns a fGPILSelection flag to indicate if the process is the selected one can be is forced or not CandidateForSelection this process can be the winner If its step length is the smallest it will be the process defining the step the pro cess NotCandidateForSelection this process cannot be the winner Even if its step length is taken as the smallest it will not be the process defining the step The method G4SteppingManager InvokeAlongStepDoIts isin charge of calling the AlongStepDolt methods of the different processes e If the current step is defined by a ExclusivelyForced PostStepGet PhysicalInteractionLength no AlongStepDolt method will be invoked e Else all the active continuous processes will be invoked and they return the ParticleChange After it for each process the following is executed 12 Update the G4Step information by using final state information of the track given by a physics process This is done through the UpdateStepForAlongStep method of the ParticleChange Then for each secondary x t is checked if its kinetic energy is smaller than the energy threshold for the material In this case the particle is as signed a 0 kinetic energy and its energy is added as de posited energy of the parent track This check is only
12. G4NavigationHistory from volumes BackLevel G4NavigationHistory lt lt const gt gt GetDepth lt lt const gt gt GetTopTransform lt lt const gt gt GetTopVolume G4VTouchable X G4GRSSolid G4GRSVolume G4TouchableHistory from volumes from volumes from volumes A A A X X X G4GRSSolidHandle G4GRSVolumeHandle G4TouchableHistoryHandle G4TouchableHandle from volumes from volumes from volumes V T gt G4ReferenceCountedHandle from global Figure 37 Reference counting for touchables 68 G4SmartVoxelProxy G4SmartVoxelProxy O GetHeader GetNode 1 VIsHeader G4SmartVoxelNode 0 fcontents G4SliceVe X fNodg 1 GetMaxEquivalentSlice UR GetMinEquivalentSlice Li GetNoContained Getvolume insert 1 fcontents i y 2 1 1 G4SliceVector G4ProxyVector F fslices b 7 7 gt x z 3 p U n x G4VoxelLimits G4int E from globall N Yer SaddLimit AE clipToLimits vector GetMaxExtent e ues from STL std GetMinExtent Inside Pout Code Figure 38 Smart Voxels 69 G4DrawVoxels 7 createPlaced
13. Russian dolls ar chitectural pattern Abstract classes are used as the delegation mechanism All framework functional requirements were obtained through use case anal ysis In the following we present for each framework level the compressed use cases requirements designs including the flexibility provided and illus trate the framework functionality with examples All design patterns cited are to be read as defined in 2 4 4 3 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 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 The same can be achieved with template specialisations with slightly improved CPU performance but at the cost of significantly more complex designs and with present com pilers significantly reduced portability 43 for hadronic processes for particles at rest GAVRestProcess
14. VRegisterlsotopeProductionModel lt lt static gt gt EnablelsotopeProductionGlobally lt lt static gt gt DisablelsotopeProductionGlobally EnablelsotopeCounting DisablelsotopeCounting lt lt Concrete gt gt 4 G4EnergyRangeManager lt lt Abstract gt gt 1 4HadronicInteraction o G4Element GetHadronicinteraction gt en ApplyYourself SetMinEnergy 0 e SetMaxEnergy puo i A d gt G4Material lt lt Concrete gt gt ConcreteModel Figure 21 Level 2 implementation framework of the hadronic category of GEANTA final state production aspect AT Isotope production Forisotope production a base class GAVIsotopeProduction is provided It declares a method G4IsoResult GetIsotope const G4Track amp const G4Nucleus amp 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 re stricted 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
15. also set validNorm to either e true if the solid lies entirely behind or on the exiting surface Then it must set n to the outwards normal vector the Magnitude of the vector is not defined e false if the solid does not lie entirely behind or on the exiting surface If calcNorm is false then validNorm and n are unused G4bool CalculateExtent const EAxis pAxis const G4VoxelLimits amp pVoxelLimit const G4AffineTransform amp pTransform G4double amp pMin G4double amp 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 inter sected 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 35 std ostream amp StreamInfo std ostream amp 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 vis
16. 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 lt lt Abstract gt gt G4HadronicProcess lt lt virtual gt gt GetMicroscopicCrossSection amp lt lt virtual gt gt PostStepDolt S RegisterMe S ChooseHadronicInteraction S GeneralPostStepDolt lt lt static gt gt GetlsotopeProductioninfo S RegisterlsotopeProductionModel amp lt lt static gt gt EnablelsotopeProductionGlobally amp lt lt static gt gt DisablelsotopeProductionGlobally EnablelsotopeCounting DisablelsotopeCounting 0 lt lt Concrete gt gt G4lsoParticleChange lt lt Purely Abstract gt gt G4VIsotopeProduction Getlsotope lt lt Concrete gt gt G4NeutronlsotopeProduction Figure 22 Level 2 implementation framework of the hadronic category of GEANT isotope production aspect 48 neutrons are encountered In all other conditions the system falls back on the default or data sets with ear
17. done if the flag ApplyCutFlag is set for the particle by default it is set to false for all particles user may change it in its G4VUserPhysicsList If the track has the flag IsGoodFor Tracking true this check will have no effect used mainly to track particles below threshold The parentID and the process pointer which created this track are set The secondary track is added to the list of secondaries If it has 0 kinetic energy it is only added if it it invokes a rest process at the beginning of the tracking The track status is set according to what the process defined The method G4SteppingManager InvokePostStepDolts is on charge of calling the PostStepDolt methods of the different processes e Invoke the PostStepDolt methods of the specified discrete process the one selected by the PostStepGetPhysicalInteractionLength and they return the ParticleChange The order of invocation of processes is inverse to the order used for the GPIL methods After it for each process the following is executed Update PostStepPoint of Step according to ParticleChange Update G4Track according to ParticleChange after each PostStep Dolt Update safety after each invocation of PostStepDolts The secondaries from ParticleChange are stored to SecondaryList Then for each secondary t is checked if its kinetic energy is smaller than the energy threshold for the material In this case the particle is as signed a 0 kinetic energy and
18. 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 SteppingO is the key to managing one step The algorithms used in these methods are ex plained below ProcessOneTrack in G4TrackingManager 1 Actions before tracking the particle Clear secondary particle vector 2 Pre tracking user intervention process 10 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 e Call Stepping method of G4SteppingManager e Append a trajectory point to the trajectory object if it is requested 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 InvokeAtRestDoltProcs for the selected AtRest processes 3 If particle is not stopped e Invoke DefinePhysicalStepLength that finds the minimum step length demanded by the active processes e Invoke InvokeAlongStepDoltProcs e Update current track properties by taking into account all changes by AlongStepDolt e Update the safety e Invoke PostStepDolt of the active
19. fireArray H shoot Sie i 0 n Je PSS shootArray Xs fireArray SES fireArray E ono E A N 0 n ae i p Figure 14 HEPRandom module 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 e B H Flowers An introduction to Numerical Methods In C Clare don Press Oxford 1995 e M Abramowitz I Stegun Handbook of mathematical functions DOVER Publications INC New York 1965 chapters 9 10 and 22 28 ES ES Just one of the following ES Random Engines at a time Y gt 2 ro Is active HepRandomEngin z HepJameshandom default epRando gine DRand48Engine A BandEn ine RanluxEngine RanecuEngine U La G 2 setSeed long y 1 setTheEngine PEA theEngine RandGauss f gt e ye theGenerator 7 flat a 10 flat RandBreit ll A Br 17 shoot Wigner Y NI 3 flat lt A AR 13 flat shoot 7 Ta aGenerator v 1e flat G HepRandom uil e 6 flat G IES RNA n d G RandPoisson gt vi TT c g shoot 14 shoot
20. 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 pro duction 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 lt lt Concrete gt gt G4PartonTransportModel lt lt Concrete gt gt G4PythiaAhinterface _ lt lt Abstract gt gt G4NhModel Scatter GetWoundedNucleus 1 lt lt Concrete gt gt G4PythiaNhinterface lt lt Abstract gt gt lt lt Concrete gt gt G4TheoFSGenerator G4HadronicInteraction Apply Yourselt Apply Youself SetMinEnergy SetMaxEnergy DeActivateFor 5 lt lt Purely Abstract gt gt G4VHighEnergyGenerator Scatter S GetWoundedNucleus li lt lt Abstract gt gt G4VPartonStringModel Scatter Pinit Q lt c lt virtual gt gt GetStrings Sf CorrectHadronMomenta PeSetThisPointer 1 Purely Abstract x aa Apply Y
21. ouself SDeExcite S SetExcitationHandler amp G4VPreCompoundModel amp G4VPreCompountModel lt lt Purely Abstract G4VintraNuclearTransportModel Y Apply Y ourself SPropagate 1 lt lt Concrete gt gt G4VExcitationHandler S BreakltUp lt lt Concrete gt gt G4QMDModel lt lt Concrete gt gt G4HadronKineticModel G4HadronicCascade lt lt Concrete gt gt Figure 23 Level 3 implementation framework of the hadronic category of GEANT4 theoretical model aspect 50 7T 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 ab stract base classes have been implemented e GAVHighEnergyGenerator e GAVIntranuclearTransportModel e G4VPreCompoundModel e GAVExcitationHandler In addition the class GATheoFSGenerator is provided to orchestrate inter actions 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 de clares 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 App
22. production information from the final state given by the transport model In addition it provides a registering mechanism for isotope pro duction 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 en sure 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 49 precision low background experiment 4 4 5 Level 3 Framework Theoretical Models GEANT4 provides at present one implementation framework for theory driven models The main use case is that of a user wishing to use theoretical mod els in general and to use various intra nuclear transport
23. 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 aggre gation 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 avoid
24. 4HCtable a G4SteppingMan ement treeTop ager from Tracking Au pap n 1 m od 2 Der A EE RR k v pie Sena ST X G4SDStructure X AM UR GALogicalVolume manager TT activate ti 7 G4HCofThisEvent y from Geometry N addNewDetector e add hitsCollection p Sy getSD get HC f N Ss initialize i get_capacity N terminate _ 7 7 get numberOfCollections rez detector __ j et SensitiveDetector 3 e aa fe gt G4VSensitiveDetector t p G4Step activate i from Tracking clear Y E MEN S drawAll G4VhHitsCollection x j 4 P SDname G4Sting EA lame aCollection SDpathName G4String getName collectionName G4String getPathName i SERI get numberOfCollections j G4VReadOut ali d DNO sem i Geometry Las Lw isActive or pl NS pd j j printAli G4VHit Sion LS _ processHits xc draw TT i A print i Figure 5 Overview of hit classes management GAVSensitiveDetector NN ensitiveDetector o HitsCollection These derived classes are j j just examples ES i Implementations should be done by drawAll e users accoring to their actual E endOfEvent y detector setups Ya getName processHits Aa P VE ym calorimeterHitsColle gt
25. Bl comandTree z Seren euer M j gt 1 f lt 2 N AS eere nd i gt X pen gt da These two classes are shown just for E M illustrating how classes in other SUA ig a Nae ak ela J categories use the messenger 7 G Ulbatch Y SE 1 Mewes q 7 4 messengerA should Know all of G4Ulterminal FI V ER nessesary set get methods of K 7 77 N classA and should be writen by the N auther of class gt N hi command dd H N aet T dui guidance N bali gt N messeriger X 7 on 7 TN PESIN YAZ j j gi G4Ulparameter DN G4Ulcommand a It list H secure aue 0 Il i G String 7 it omitt Il commandGL dance G4String Parameter arameterGuidance G4String commandName G4String Ji G4String uM gt Ji parameterRange G4String x i ParameterType char i af V gt lt v p uu Figure 18 Overview of user interface classes 32 4 Guide to extend Geant4 class functionality 4 1 Geometry 4 1 1 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
26. Geant4 User s Guide For Toolkit Developers December 6 2004 Contents 1 Introduction 4 1 1 Scope of this manual eue KI K K K K 4 1 2 How to use this manual x m p ib fek be RARE 4 1 36 Status of Chis chapleteo o aruba a dira 8 Hol etes 5 2 User requirements document 5 2 1 Source of User Requirement Document 5 3 Object oriented Analysis and Design of Geant4 Categories 6 3 1 Run and Event Categories 6 dl AURACKING p un cid dude aa o 7 3 2 1 Design Philosophy ls bu e KI K K ae 7 3 22 Glassa amp dite ee 8 3 2 3 Tracking Algorithm e qi a eg ens rece delen 10 3 2 4 Interaction with Physics Processes 12 3 2 5 Ordering of Methods of Physics Processes 15 3 2 6 Status of Tracking section 16 3 3 Physics Processes 1 K K K K K K K K 2 eR 16 de General x u ne sube dr ud sas aps 16 DA Hita ia A EJ NDM IM t 16 3 05 Geometry s gt andae ac eoa de dence E e e 16 3 6 Electromagnetic Fields 2 12 2 22 ete Particles s turbet eer delen nha tee be ft bem pr b ber Morus 23 Qm Materials 54 f b cia er pr e oo aL dr dd 25 mu Global Mar allem dia k epi or IPRC Reg 26 3 9 1 The global class category 26 BOD desiti ig 2 2 tie ds Moe e pro 27 3 9 3 Status of this section 3 05 2 0 842440 a 30 VOW ISAO e sese A A E 30 3 10 1 Visu
27. ParticleDefinition from Track n Ger 4 GetMomentumDirection N fpPreStepPoint er GetTotalEnergy fpPostStepPoint Figure 3 Management of Physics Processes 17 G4VRestContinouousDis crete Wee ee P Process ER pres A os 4 AtRestDolt Pa Xer ez a Sal 5 P GetMeanFreePath PS longStepDolt 1 GetMeanLifeTime i A G4VProcess GetContinuousStepLimit PostStepDolt i p 4 AlongStepDolt AtRestDolt AlongStepDolt i AlongStepGetPhysicallnteractionLength j GetMeanLifeTimet GetContinuousStepLimit __ AtRestDolt 27 d k V EM AtRestGetPhysicallnteractionLength ASA P gue M PostStepDolt ten 4 ra Slug NP S PostStepGetPhysicallnteractionLength G4VRestProces G4VContinousDiscrete i AN a Process AR l w 5 j lt EE N n AlongStepDolt Y PM SS i EN GetMeanFreePath P A E DES PostStepDolt i V DAP Soc Erd T GetContinuousStepLimit G4VRestDiscreteProcess MN QW P ra G4VContinuousProcess gt 7 LD AtRestDolt e i E s GetMeanLifeTime g F AlongStepDolt P G4VDiscreteProcess gt GetMeanFreePath ZZ GetContinuousStepLimit La GetMeanFreePath E PostStepDolt OR PostStepDolt EM 1 G4hEnergyLoss SAN 1 AlongStepDol W E PostStepDolt aa On GetCo
28. Polyhedra DrawVoxels setVoxelsVisAttributes amp ES freplicaNav x N 1 k Figure 39 Navigator 70 Figure 40 Regions 71
29. SE Seat fy 12 flat gt i NE RA N Si RandExpo on ON entia 4 11 shoot S UNI Sa RandFlat gt N Q Figure 15 Shooting via the generator f DT Pi localEngine 1 flat ss NET 9 A 4 flat ja v fi Flaibisti fire W 4 fire NC ution Distrib mer o Ftion ribution E Mal a 10 fire K PoissonDi E stribution 8 fire S S O d BWDistribu pe tion FO TA Figure 16 Shooting via distribution objects HEPGeometry Documentati in the CLHEP Reference Guide http cern ch wwwasd lhc CLHEP User Manual http cern ch wwwasd lhc on for the HEPGeometry module is provided clhep manual RefGuide index html or the clhep manual UserGuide index html 29 PoissonDi gt C stribution FatDistib ee A Da 6 shoot d Swat EU ExpDistrib o e gt Be TL ribution 4 gt poe Las E ST J l PAE j Lai Ne Figure 17 Shooting with arbitrary engines 3 9 3 Status of this section 01 12 02 minor update by G Cosmo 3 10 Visualization 3 10 1 Visualization Manager The Visualization Manager is implemented by G4VisManager and its de scendant 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 3 10 2 Visualization dr
30. a new type of solid in GEANT4 Note that GEANT4 s specifications for a solid pay significant at tention 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 33 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 vir tual of G4VSolid EInside Inside const G4ThreeVector amp p G4double DistanceToIn const G4ThreeVector amp p G4double DistanceToIn const G4ThreeVector amp p const G4ThreeVector amp v G4ThreeVector SurfaceNormal const G4ThreeVector amp p G4double DistanceToOut const G4ThreeVector amp p G4double DistanceToOut const G4ThreeVector amp p const G4ThreeVector amp v const G4bool calcNorm false G4bool validNorm 0 G4ThreeVector n G4bool CalculateExtent const EAxis pAxis const G4VoxelLimits amp pVoxelLimit const G4AffineTransform amp pTransform G4double amp pMin G4double amp pMax const G4GeometryType GetEntityType const std ostream amp StreamInfo std ostream amp os const They must perform the following functions EInside Inside const G4ThreeVector amp p This meth
31. al 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 GEANTA 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 42 4 4 2 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 re lease of the program The implementation frameworks follow the Russian dolls approach to implementation framework design A top level very ab stracting 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 hier archy 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
32. alization Manager 30 3 10 2 Visualization drivers XY la ta K K K K dee a 30 3 10 3 Modeling sub category 04 24 65 KI os 31 3 10 4 View parameters 2 e up Pp uc RP S 3l SET ser Interface zen mota sal S hyper vp ard xe IDE 92 4 Guide to extend Geant4 class functionality 33 LE OIM aa rn 33 4 1 1 Whatcanbeextended 33 4 1 2 Adding a new type of Solid 33 4 1 8 Modifying the Navigator 37 4 2 Electromagnetic Fields e Ss ge e ei a KK 38 4 2 1 Creating a new type of Field 38 4 2 2 Status of the section ofan KK KI KI 6 wien K K Je 42 4 3 Physics Processes i ars ses AENA DE 42 4 4 Extending hadronic physics functionality 42 dar rus c4 eee Gn PLE e ERE HEX IER 42 442 Principal considerations 43 443 Level 1 Framework processes 43 4 4 4 Level 2 Framework Cross sections and Models 45 4 4 5 Level 3 Framework Theoretical Models 50 4 4 6 Level 4 Frameworks String Parton Models and Intra Nuclear Cascade 5 2 4 Put p det k k 2 52 4 4 7 Level 5 Framework String De excitation 54 dio Wiel Zek GM deii quete ape gg 56 5 Appendix 57 5 1 Class Diagrams for the GeometryCategory 57 1 Introduction 1 1 Scope of this manual The scope of this manual is to provide detailed information about the de sign
33. asses related to the particle decay table 23 EPIS K G4Proton eksenine lt PONS G MuonMinus G4PionPlus _G4Proton _ O GetCut E i Ses ES Skik i n E y Secus M Secus Proton and many others e i LD i u 11 vo AR K C 2 G4WMeso G4VBaryon on gt G4VBoson z G4VLepton a G eson ion j j P y as LM E P We p J GALossVect MG ue G4LossTable gt PS SARA di 2 insert ra G4AMaterial G4ParticleWithCuts ATA j a from Materials SetCuts A hheLosstable E g r sise Su 0 n a BuildPhysicsTable vo Sa CalcEnergyCuts i D C sj pe k ComputeLoss x p qos SUN d BN GetLengthCuts 34RangeVector Fe P dE muse 7 X GetEnergyCuts GetValue G4LossVector nd Ns yerimin c PutValue pi Getvalue G4Allocator Ae soa E i Ss PutValue from Globals A ES j PA G4ParticleDefinition m qued Ad thePDGMass G4double CE AG Bese SETA Xw theParticleName G4String 1 _ G4Process G4DynamicParticle N thePDGEncoding G4int OjF treProcessMenago __ Manager GetMomentumDirection 1 ithePariceBefitl n X from PhysicsProcess i GetTotalEnergy Dd GetPolarization
34. cVector G4int te NAS ie gt T gt aProcess G4VProcess j x 1 i 2 E gt 1 1 G4RWTProcess P Vector ol p ESSE Sek N _ RWTValordered 5 ES G4VProcess be WE D amp Tani AME amp pirNextTable ji TW G4ProcessVector y s Vector 1 Y G4PhysicsVector gt GetValue A I p E PutValue Mai j 4 G4DataVector j dataVector z G ParticleChange 5 5 from Track e Initialize P Sa AddSecondary Kort gt a DN Clear G4PhysicsLinear i eins Change i Vector of epee etMomentumChange _ CA n gt BetLocalEnergyDeposii 1 5 TEE as and others with secondaries aPariidteChange T V 4 arbitrary binning pr ae V G4VProcess L Nu n AlongStepDolt T7 i Tu Y G 4Track y y AlongStepGetPhysicallnteractionLength a _ from Track 2 AtRestDolt Pale i Position G ThreeVecfl r 7 AtRestGetPhysicalinteractionLength GaMateral BuildPhysicsTable GetPhysicsTable GetProcessName i a Time G4double oh from Materials t y VE 1 ES PostStepDolt y DynamibParticle X PostStepGetPhysicallnteractionLength i gt pa A e j G4DynamicParticle G4Step y pie Pe 6 from
35. ding 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 e In the loop of GetPhysicalInteractionLength of AlongStepDolt the Transportation process has to be invoked at the end e In the loop of GetPhysicalInteractionLength of AlongStepDolt the Multiple Scattering process has to be invoked just before the Transportation process 2 Ordering of Dolts e There is only some special cases For example the Cherenkov process needs the energy loss information of the current step for its DoIt invocation Therefore the EnergyLoss process has to be invoked before the Cherenkov process This ordering is provided by the process manager Energy loss information necessary for the Cherenkov process is passed using G4Step or the static dE dX table is used together with the step length information in G4Step to obtain the energy loss information Any other 15 3 2 6 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 References 1 Geant4 Use
36. discrete process e Update the track length e Send G4Step information to Hit Dig if the volume is sensitive e Invoke the user intervention process e Return the value of the StepStatus 11 3 2 4 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 Dolt 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 e Obtain maximum allowed Step in the volume define by the user through G4UserLimits e The PostStepGetPhysicalInteractionLength of all active processes is called Each process returns a step length and the minimum one is chosen This method also returns a G4ForceCondition flag to indicate if the process is forced or not Forced Corresponding PostStepDolt is forced NotForced Corresponding PostStepDolt is not forced un less this process limits the step Conditionally Only when Along StepDolt limits the step corresponding PoststepDolt is invoked ExclusivelyForced Corresponding PostStepDolt is exclusively forced All other Dolt including AlongStepDolts are ignored e The
37. dronicProcess which holds a list of cross section data sets The term data set is repre senting an object that encapsulates methods and data for calculating total cross sections for a given process in a certain range of validity The implemen tations may take any form It can be a simple equation as well as sophisti cated parameterisations or evaluated data All cross section data set classes are derived from the abstract class G4VCrossSectionDataSet which declares lt lt Abstract gt gt G4HadronicProcess amp lt lt virtual gt gt GetMicroscopicCrossSection amp lt lt virtual gt gt PostStepDolt S RegisterMe S ChooseHadroniclInteraction S GeneralPostStepDolt S static GetlsotopeProductionInfo S RegisterlsotopeProductionModel amp lt lt static gt gt EnablelsotopeProductionGlobally amp lt lt static gt gt DisablelsotopeProductionGlobally YEnablelsotopeCounting B DisablelsotopeCounting lt lt Concrete gt gt lt lt Concrete gt gt lt lt Concrete gt gt lt lt Concrete gt gt G4HadronFissionProcess G4HadronlnelasticProcess G4HadronElasticProcess G4HadronCaptureProcess pepe lt lt Concrete gt gt 5 G4CrossSectionDataStore AddDataSet S GetCrossSection lt lt Concrete gt gt 10 ADataSet Purely Abstract DTE G4VCrossSectionDataSet
38. e 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 4 2 Electromagnetic Fields 4 2 1 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 i
39. e physics interactions The hierarchical design of the physics in teractions enables the stepping manager to handle them as abstract objects Hence the manager is not concerned with concrete interac tion objects such as bremsstrahlung or pair creation The actual in vocations of various interactions during the stepping are done through a dynamic binding mechanism This mechanism shields the tracking category from any change in the design of the physics process classes including the addition or subtraction of new processes G4SteppingManager also aggregates the pointers to G4Navigator from the geometry category to the current G4Track and the list of secondaries from the current track through a G4TrackVector to G4UserSteppingAction and to G4VSteppingVerbose It also has a use relation to G4ProcessManager and G4ParticleChange in the physics processes class category e G Track the class G4Track represents a particle which is pushed by G4SteppingManager It holds information required for stepping a par ticle for example the current position the time since the start of step ping the identification of the geometrical volume which contains the particle etc Dynamic information such as particle momentum and en ergy is held in the class through a pointer to the GADynamicParticle class Static information such as the particle mass and charge is stored in the G4DynamicParticle class through the pointer to the G4ParticleD
40. eate a realistic ren dering 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 GANURBS CreateNURBS const is not currently utilised so you do not have to implement it 4 1 3 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 exchang ing or extending the G4Navigator by introducing an abstraction level sim plifying the customisation At this time a simple abstraction level of the navigator is provided by allowing overloading of the relevant functionalities 3T would fit Extending the Navigator The main responsibilities of the Navigator are e locate a point in the tree of the geometrical volumes e compute the length a particle can travel from a point in a certain direction before encountering a volume boundary The Navigator utilises one helper class for each typ
41. ed 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 3 2 2 Class Design Fig not yet available shows a general overview of the tracking design in Unified Modelling Language Notation e G TrackingManager is an interface between the event and track cat egories and the tracking category It handles the message passing between the upper hierarchical object which is the event manager G4EventManager and lower hierarchical objects in the tracking cate gory GATrackingManager is responsible for processing one track which it receives from the event manager G4TrackingManager aggregates the pointers to G4SteppingManager G4Trajectory and G4UserTrackingAction It also has a use relation to G4Track e G SteppingManager plays an essential role in particle tracking It per forms message passing to objects in all categories related to particle transport such as geometry and physics processes Its public method Stepping steers the stepping of the particle The algorithm em ployed in this method is basically the same as that in Geant3 The GEANT4 implementation however relies on the inheritance hierarchy of th
42. efinition class Here the aggregation hierarchical de sign is extensively employed to maintain high tracking performance e G4TrajectoryPoint and G4 Trajectory the class GATrajectoryPoint holds the state of the particle after propagating one step Among other things it includes information on space time energy momentum and geometrical volumes G4Trajectory aggregates all GATrajectoryPoint objects which belong to the particle being propagated G4TrackingManager takes care of adding the G4TrajectoryPoint to a G4Trajectory object if the user requested it see 1 The life of a G4Trajectory object spans an event contrary to G4Track objects which are deleted from memory after being processed e G4UserTrackingAction and G4UserSteppingAction GAUserTrackingAction is a base class from which user actions at the beginning or end of track ing may be derived Similarly GAUserSteppingAction is a base class from which user actions at the beginning or end of each step may be derived 3 2 3 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 nec essary 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 IrackingManager object delegates management of
43. el of a nucleus and the logic of scatter ing 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 4 4 7 Level 5 Framework String De excitation The use case of this level is that of a user or theoretical physicist wishing to understand the systematic effects involved in combining various fragmenta tion 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 54 Requirements 1 Allow the selection of fragmentation function Design and interfaces A base class for fragmentation functions GAVFragmentationFunction 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 of the hadron
44. equirements Document is http cern ch geant4 00AandD URD pdf LL Benes dic A tto 84 ae P 7 n G4StackedTrackCo AN G4OODBMSInt NE A NUUS from Di en Ci f DEC 7 stackPrimaries x rom CODES Weje re 3 Su store Trajectories So 1 trackContainer__ stackSecondaries summaryOfEvent jJ OwelghiControl G bool LA QU qae Neca ax x p e T U a m GAVisualization RE from Visualisation drawTrajectory i o initializeEvent trackSelector 1 n i stackedTrack N A 7 trackSelector 54 Noc 1 E n NS fs ae AER gt 1 id Jt G StackedTrack Ts G4TrackSelecto y G4TrajectoryCo priority Weight Gadouble ER rd ntainer 0 f ishNewTrajectory E toBeStored trajectorySelector Qe pus lewTrajectory ds weightThreshold EM ui Ha 7 ector A primaryGenerator 9 A gt from BaseClass WV pr N Le 7 p pen trajectorySelector SEES lt G4UserTrack G4TrajectorySelect ra Selector 1 Y oF x ESE 1 ezen a au T P G4EventGenerator lt gt MER track Noe
45. from nero Y v G4TrackingManager trajectory A generate_one_event from TrackManagement gimmeSecondaries Sy gimme Trajectory processOneTrack y e 5 gt GaUgerTrajectory 1 bw hizo Y Le gt A a ue GE V Ate k da e G4Track TUN ME N from TrackManagement 1 d E e i Pd is de n i sal EN Sar gt i S e YA lt gt Pe ni v AES n Re lt OA F 7 Gibran Sg Vi G4Trajectory 5 Y G4PrimaryVertex j GaTrackVactor yA Dynamiek arei from ParticleDefinition y from EventGenerator Ear d ff f from TrackManagement from PhysiosProcess E Sa n ha J E E ge J gt e EE o E TTL ARR N P ee OS x gi M a Nae DEN LE File users asai g4 v_0830 mdl Thu Aug 31 14 00 49 1995 Class Diagram EventManagement Main Figure 1 Event 3 Object oriented Analysis and Design of Geant4 Categories 3 1 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 VER SAP va gt an r KMN G4EventGenerator 7 addGenerator jz generateOneEvent i gimmeVertex hes N E ecl G4OrderedV IM
46. gions 57 G4VSolid fMateri G4Material from materials G4FieldManager from magneticfield G4LogicalVolumeStore lt lt static gt gt DeRegister S static GetInstance S static Register G4VPhysicalVolume 1 flogical E G4PhysicalVolumeList 1 from G4LogicalVoljme f D au rs 1 0 G4VSensitiveDetector PSensitiveDe from digitsthits fVoxel 0 GasmartvoxelHeaddr fUserLimits G4UserLimits from global Figure 27 Logical volumes 08 G4LogicalVolume amp fName G4String AddDaughter lt lt const gt gt lt lt const gt gt lt lt const gt gt lt lt const gt gt lt lt const gt gt GetDaughter GetMaterial GetName GetNoDaughters GetSolid RemoveDaughter G4PVPlacement G4PVReplica G4PVPlacement G4PVReplica CcheckAndSetParamete G4PVParameterised G4PVParameterised i fparam 0 G4VPVParameterisation lt lt virtual gt gt ComputeDimensions amp lt lt virtual gt gt ComputeMaterial S virtual ComputeSolid lt lt virtual gt gt ComputeTransforma Figure 28 Physical volumes 59 G4VoxelLimits from manage
47. icleChange The order of invocation of processes is inverse to the order used for the GPIL methods After it for each process the following is executed Set the current process as a process which defined this Step length Update the G4Step information by using final state information of the track given by a physics process This is done through the UpdateStepForAtRest method of the ParticleChange The secondaries from ParticleChange are stored to SecondaryList Then for each secondary t is checked if its kinetic energy is smaller than the energy threshold for the material In this case the particle is as signed a 0 kinetic energy and its energy is added as de posited energy of the parent track This check is only done 14 if the flag ApplyCutFlag is set for the particle by default it is set to false for all particles user may change it in its G4VUserPhysicsList If the track has the flag IsGoodFor Tracking true this check will have no effect used mainly to track particles below threshold The parentID and the process pointer which created this track are set The secondary track is added to the list of secondaries If it has 0 kinetic energy it is only added if it it invokes a rest process at the beginning of the tracking The track is updated and its status is set according to what the process defined 3 2 5 Ordering of Methods of Physics Processes The ProcessManager of a particle is responsible for provi
48. ination 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 GAVPreCompoundModel 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 GAVExcitationHandler 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 GATheoFSGenerator receives the conditions of the interaction a primary particle and a nucleus It asks the dual parton model to perform the initial scatterings and re turn the final state along with the by then damaged nucleus The nucleus records all information on the damage sustained G4TheoFSGenerator for wards all information to the classical cascade that propagates the particles in the already damaged nucleus keeping track of interactions further dam age to the nucleus etc Once the cascade assumptions break down the cascade will collect the information of the current state of the hadronic sys tem like excitation energy and number of excited particles and interp
49. ing 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 G4V Model defines a model which describes how to visualize the cor responding 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 amp 0 The argument class G4VGraphicsScene is a minimal abstract interface of a 3D scene for the GEANT4 kernel defined in the graphics_reps cate gory 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 visual izable component object It is done by implementing a new class inheriting from G4V Model 3 10 4 View parameters View parameters such as camera parame
50. ithPlane 4 0 1 projectedBoundary d 57 E Figure 34 BREP surfaces 65 G4ReflectionFactory amp fInstance G4ReflectionFactory amp fReflectedLVMap LogicalVolumesMap VPlace Replicate SetVerboseLevel lt lt const gt gt GetVerboseLevel lt lt static gt gt Instance G4ReflectedSolid amp DirectTransform3D G4Transform3D amp fPtrSolid G4VSolid ComputeDimensions SetDirectTransform3D lt lt const gt gt CalculateExtent lt lt const gt gt DistanceToln lt lt const gt gt Distance ToOut lt lt const gt gt GetDirectTransform3D lt lt const gt gt Inside lt lt const gt gt SurfaceNormal lt 1 E Figure 35 Reflections of solids 66 HfDirectTransform3p PtrSolid 1 G4Transform3D from global G4VSolid from management amp fshapeName G4String G4VSolid G4GRSSolid from volumes G4GRSSolid Lesolia O G4VSolid lt ftlate G4ThreeVector from global from global G4RotationMatrix G4GRSVolume from volumes 1 GAGRSVolume G4VPhysicalVolume amp fname G4String lt lt const gt gt GetName Figure 36 Touchables 67 fhistory
51. its energy is added as de posited energy of the parent track This check is only done 13 if the flag ApplyCutFlag is set for the particle by default it is set to false for all particles user may change it in its G4VUserPhysicsList If the track has the flag IsGoodFor Tracking true this check will have no effect used mainly to track particles below threshold The parentID and the process pointer which created this track are set The secondary track is added to the list of secondaries If it has 0 kinetic energy it is only added if it it invokes a rest process at the beginning of the tracking The track status is set according to what the process defined The method G4SteppingManager InvokeAtRestDolts is called instead of the three above methods in case the track status is fStopAndA Live It is on charge of selecting the rest process which has the shortest time before and then invoke it e To select the process with shortest tiem the AtRestGPIL method of all active processes is called Each process returns an lifetime and the minimum one is chosen This method returm also a G4ForceCondition flag to indicate if the process is forced or not Forced Correspond ing AtRestDolt is forced NotForced Corresponding AtRestDolt is not forced unless this process limits the step e Set the step length of current track and step to 0 e Invoke the AtRestDolt methods of the specified at rest process and they return the Part
52. ivers 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 G4V View respectively an ar bitrary 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 graph ics 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 visualiza tion driver For example the DAWN File driver which is the interface to Fukui Renderer DAWN is implemented by the following set of classes 1 GADAWNF LE public G4VGraphicsSystem for initialization 30 2 GADAWNFILESceneHandler public G4VSceneHandler for modeling 3D scenes 3 GADAWNFILEView public G4V View 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 3 10 3 Modeling sub category The sub category visualization model
53. lier 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 nuclear interactions that might be used for e e 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
54. lyYourself 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 GAVPreCompoundModel inherits from G4HadronicInteraction again making any concrete imple mentation usable as stand alone model It adds a pure virtual DeExcite method for further evolution of the system when intra nuclear transport as sumptions break down DeExcite takes a G4Fragment the GEANT4 repre sentation of an excited nucleus as argument The base class for evaporation phases GAVExcitationHandler 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 GAVIntranuclearTransportMode 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 appli cation of this pattern is the use of parton string models for string excitation 51 quark molecular dynamics for correlated string decay and quantum molec ular dynamics for transport a comb
55. ment AddLimit clipToLimits GetMaxExtent G4SolidStore GetMinExtent from management SInside IsLimited Pout Code H lt lt static gt gt DeRegister gt lt lt static gt gt GetInstance G4LogicalVolume lt static gt gt Register from management A Name G4String N 2 lt lt const gt gt GetName ke G4VSolid from management solide pfshapeName G4String 1 lt lt virtual gt gt CalculateExtent S virtual ComputeDimensions lt lt virtual gt gt DistanceToIn lt lt virtual gt gt DistanceToOut lt lt const gt gt GetName lt lt virtual gt gt Inside lt lt virtual gt gt SurfaceNormal G4CSGSolid G4cscsolid 60 Figure 29 CSG solids G4VSolid from management amp fshapeName G4String G4CSGSolid S virtual CalculateExtent S virtual ComputeDimensions S virtual CreatePolyhedron lt lt virtual gt gt DistanceToIn S virtual DistanceToOut lt lt virtual gt gt Inside lt lt virtual gt gt SurfaceNormal G4BooleanSolid lt lt virtual gt gt GetConstitue Figure 30 Boolean solids 61 G4CSGSolid G4VSolid from management amp fshapeName G4String
56. n 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 fol lowing 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 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 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 Fig 17 illustrates the situation when many generators are defined each by a distribution and an engine The static interface is skipped here 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 o
57. n 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 38 class NewField public G4Field 1 public void GetFieldValue const double Point 3 double pField 0 and deciding how many components your field will have and what each com ponent 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 1s 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 Poin
58. ntinuousStepLimit Tuer a GetMeanFreePath OW Qu PE ci e ant du 3 mL ta ni 2 PR Ao N MEN G4eMultipleScattering 2 L 7 EN N seu y E n J G4ComptonScattering y mngSteppo G4hlonisaton G4eplusAnnihilation G4Decay GATransportation PostDolt PostStepDolt PostStepDolt AtRestDolt Decaylt GetContinuousStepLimit y GetMeanFreePat 1 GetContinuousStepLimit GetMeanFreePath PostStepDolt GetMeanFreePath i AlongStepDolt SEM TrueGeomTransformation _ i GetMeanLifeTime GetLifeTime SN X GetMeanFreePath _ i GetMeanFreePath A 1 J P i Pd i MOR 1 gt Pd 1 VU QT u d v E E Figure 4 General Physics Processes 18 J G4SDmessi G4VICmessen ger 4 Sx 1 1 ma E enger ger y Manage G4S DManager activate addNewDetector get collectionCapacity get collectionID prepareNewEvent lerminateCurrentEvent mne j G4EventManage 4 r G4Event from EventManagement de add hitsCollection get HCofThisEvent i fm EventManagemek 7 G
59. o 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 ex plains 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 gener ator 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 4 1 design principle described in the Physics processes section of the chap ter 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 1 3 Status of this chapter 2 User requirements document 2 1 Source of User Requirement Document The Geant4 User Requirements Document follows the PSS 05 software en gineering standards A general description of the main capabilities and con strains is provided The users are characterized in different categories de pending on the level of interaction with the system Also specific require ments are listed and classified You can obtain the document by clicking the following link e URL of Geant4 User R
60. od must return e kOutside if the point at offset p is outside the shape boundaries plus Tolerance 2 e kSurface if the point is lt Tolerance 2 from a surface or e kInside otherwise G4ThreeVector SurfaceNormal const G4ThreeVector amp p Return the outwards pointing unit normal of the shape for the surface closest to the point at offset p G4double DistanceToIn const G4ThreeVector amp p Calculate distance to nearest surface of shape from an outside point p The distance can be an underestimate 34 G4double DistanceToIn const G4ThreeVector amp p const G4ThreeVector amp 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 amp p Calculate distance to nearest surface of shape from an inside point The distance can be an underestimate G4double DistanceToOut const G4ThreeVector amp p const G4ThreeVector amp 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 caleNorm is true then it must
61. 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 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 Ap plication 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 1 2 How to use this manual The manual starts with the complete reference to the user requirements doc ument 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 t
62. 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 de veloper must write a small number of methods for the new solid We will document below these methods and their specifications Note that the imple mentation 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 GEANTA solid as it implements the abstract interface of G4VSolid Other additions can also potentially be achieved For example an ad vanced user could add a new way of creating physical volumes However be cause 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 4 1 2 Adding a new type of Solid We list below the required methods for integrating
63. rMe S ChooseHadroniclnteraction GeneralPostStepDolt lt lt static gt gt GetlsotopeProductionInfo RegisterlsotopeProductionModel lt lt static gt gt EnablelsotopeProductionGlobally lt lt static gt gt DisablelsotopeProductionGlobally EnablelsotopeCounting S DisablelsotopeCounting Figure 19 Level 1 implementation framework of the hadronic category of GEANTA 44 cess 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 4 4 4 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 differ ent 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 mod els 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
64. re G4LogicalVolumeStor lt lt static gt gt De G4VSolid lt lt static gt gt Ge gt fshapeName G4String lt lt static gt gt Re lt lt virtual gt gt Inside lt lt virtual gt gt CalculateE lt lt virtual gt gt DistanceTo lt lt virtual gt gt DistanceTo lt lt virtual gt gt SurfaceNor X A G4CSGSolid from solids lt lt static gt gt DeRegister lt lt static gt gt GetInstance lt lt static gt gt Register G4PhysicalVolumeList 1 from G4LogicalVolume fDaughte 1 single touchabls G4SmartVoxelHeader A a G4AssemblyVolume L G4Box G4Tubs rom solids rom solids addPlacedvolume c4AssemblyVolume G4Box c4Tubs MakeImprint Figure 8 G4Navigator from navigation lt lt virtual gt gt ComputeStep lt lt const gt gt GetCurrentLocal lt lt const gt gt GetGlobalToLoca lt lt const gt gt GetLocalToGloba lt lt const gt gt GetWorldVolume lt lt virtual gt gt ResetHierarch setGeometricallyLimitedst setWorldvolume G4PVPlacement c4PVPlace Overview of the geometry G4VTouchable many A
65. ret 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 excita tion 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 4 4 6 Level 4 Frameworks String Parton Models and Intra Nuclear Cascade 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 52 Requirements 1 Allow to select string decay algorithm lt lt Abstract gt gt G4VPartonStringModel lt lt Purely Abstract gt gt G4VStringFragmentation SFragmentString Scatter GetWoundedNucleus genit lt lt virtual gt gt GetStrings i CorrectHadronMomenta qf SetThisPointer lt lt Concrete gt gt G4PythiaFragmentationInterface lt lt Concrete gt gt G4FTFModel lt lt Concrete gt gt ndedNucleus G4LongitudinalStringDecay a ry E
66. riginal manifesto distributed with the HEPRandom package http cern ch wwwasd geant geant4 public Random html 27 7 nur Lira flat Nur DRand48Engine flatArray RanluxEngine r U SA setSeed E ow flat flatArray gt selSeeds We flatArray setSeed I 0 n ta setSeed i z r A setSeeds i i QS WIS setSeeds j Paya ren SEA Farfa Vi n nid A On HepJamesRandom lt A Mum Sl flatArray t if HepRandomEngine P RanecuEngie gt Sa setSeed TA P ay flat setSeeds i flatArray e N fama Maa getSeed RM EE Ea eee i war 4 getSeeds a set s e a setSeed t0 n ta setSeeds a N 1 n i d NE lE wee o4 theEhgine s rc tee ue HepRandom e flat flatArray getTheEngine getTheGenerator 4 getTheSeed getTheSeeds n getTheTableSeeds setTheEngine setTheSeed setTheSeeds 1 RandFlat x i s p PN fire P SS Ps Sg 2 E N Y RandPoisson fireArray 7 Male RG an gt ES z fret e shoot D shoo gt shootArray shootArray A shootint _ ze gt Los X a fireArray i 1 0 n pa LE ua om o ia e e dd of RandGauss N EN an Vw RandExponential d shen RandBreitWigner 3 uet Fk shootArray bZ fire k shootArray S
67. rs Guide for Application Developers 3 3 Physics Processes 3 3 1 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 3 4 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 3 5 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 16 G4ProcessAttr G4ProcessAttr heA Vector G4ProcessManager EndTracking GetAlongStepProcessVector GetAtRestProcessVector i GetPostStepProcessVector GetProcessList SetProcessActivation A StartTrackin Vector Ct n g e t D let LIV GaPhysiesVector ITP i i j y n gt S ATRIDES NS ar CE 3 gt RWTPtrOrdered 7 G4ProcessAttribute G4PhysicsTable Vector M Y isActive G bool ES Lassies x from RWTools p idxProcessList Git 53 Ne idxProcVector G4int thePrabessList theProgVector ie E a ordPro
68. s eni 4 ex ee i TON 7 x j parent parent LN e 1 Y Lo channel n _ GAAllocator gt ve d AA UL MOR wau from Globals __ I G4DecayProducls N 2 E zum GetParentParticle Vector Pi RWTPtrSor Boost GetParent Ae Bog gt tedVector PushProducts GetDaughter T n 1 trom RWTools IsChecked ITools mds vov ON A j gt vi G4DecayProducks Ak N mms ListElement G4MuonD Channel N ERN next GADecayProductsListElement SOA 4 gt y SAFhassspaceDecay G4Decay a Decaylt rom Enveicar d Bee eli and many others S s TwoBodyDeca E Gav ThreeBodyDecaylt A ManyBodyD caylt j Figure 12 Particle Decay Table 3 8 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 25 pri RWTPtrOr 1 deredVect Di om RWTools lt CN Lu A gt pd C po x CS lt E dd en Gama GE ler 7 G lsot 4M sotope 5 G4Material G4Element p i 4 Tabl c Table Table N a 7m RT s AN TS A 1 TAV theMaterialTable I theElemen
69. t 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 amp the order of the components of pField is your own convention We calculate the value of pField at Point 39 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 yl 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 yl3 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 yo
70. tTable thelsotopi n d n TA E NE CPN n N 158 G4Material 3 G4Element A able P4 4 Adglsotoper i Jt mre T 10 5 SEL uad aye KON Lon ES 2 Y ez n Pd n Se i v l D s ae theElements i thelsotopes 1 1 lt Si G4Element lc gt TN i NS TTOT TT 1 LS A KN Y ax w 2 b A lt A x RWTPirve 5 ctor N from RWTools i DA yo Kait Figure 13 Materials 3 9 Global Usage 3 9 1 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 mis cellaneous 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 20 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 cat egory is given in section 3 2 of the GEANT4 User s Guide for Application Developers 3 9 2 The design HEPRandom The use of a static generator has been introduced in the original desig
71. ters drawing styles wireframe surface etc are held by G4ViewParameters Each viewer holds a view parameters 3l 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 3 11 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 P WF cC NE PEA va Rx G4VisManager G4Ulmanager visManager__ 1 addNewCommand lt 1 f applyCommand ger Deu Value M j Z getCurrentintValue p p getCurrentStringValue UlManager p getCurrentVal lues E etUIpointer zi F mi gt m uw PUR 7 cl om manager G4Ulmanager e G4Ulxvt P Sq Tese sion pen ni 2 gt A 9 a EXIT and other By J 1 Pi control i GAR commands M yt SO lt session ie TAN classA E 17 Messenger 7 pd ne x Mies B ND P ze MES i G4Ulsossion A ou geconmand y E sessionStart 7 lt y bi SEA A EN sessionTerminate G4UlcommandTres lt pet F DA dE ins aa G4Ulmessenger c A yr listCurrent N 4 N tree
72. ther 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 1 fieldExertsForce this gt 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 41 Does the particle have my field s force exerted on it if particle gt GetName VeryHeavyWIMP 4 fieldExertsForce this gt DoesGlobalFieldExist For gravity After doing all these steps you will be able to see the effects of your force on a particle s motion 4 2 2 Status of the section 10 06 02 partially re written by D H Wright 14 11 02 spell check by P Arce 4 3 Physics Processes Adding a new electromagnetic process Adding a new hadronic process 4 4 Extending hadronic physics functionality 4 4 1 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 1 facilitate the use of hadronic fin
73. to split of the string to the concrete implementation Standardisa tion in this area is expected G4ExcitedString GetPosition n GetPartonList Purely Abstracts Get4Momentum G4VStringFragmentation ___ gt InsertParton SFragmentString S TransformToCenterOfMass 4AlignAlongZ amp IsExcited amp GetHadron lt lt Concrete gt gt G4ExcitedStringDecay Purely Abstract gt gt G4VFragmentationFunction GetLightConeZ lt lt Concrete gt gt lt lt Concrete gt gt G4QGSMFragmentation lt lt Concrete gt G4LundStringFragmentation amp GetLightConeZ G4FeynmanFragmentation GetLightConeZ amp GetLightConeZ Figure 26 Level 5 implementation framework of the hadronic category of GEANT4 string fragmentation aspect 55 References 1 The GEANT 4 Collaboration CERN DRDC 94 29 DRDC P58 1994 2 E Gamm et al Design Patterns Addison Wesley Professional Com puting 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 col lisions H Stocker et al Nucl Phys A538
74. u alisation The first method is mandatory and the next four are not Mandatory virtual void DescribeYourselfTo G4VGraphicsScene amp scene const 0 Not mandatory virtual G4VisExtent GetExtent const virtual G4Polyhedron CreatePolyhedron const virtual G4NURBSx CreateNURBS O const virtual G4Polyhedron GetPolyhedron O const What these methods should do and how they should be implemented is described here void DescribeYourselfTo G4VGraphicsScene amp 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 amp scene const f Scene AddThis this The method G4VisExtent GetExtent const 36 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 1 Define the sides of the box into which the G4Tubs instance return G4VisExtent fRMax fRMax fRMax fRMax fDz fDz The method G4Polyhedron CreatePolyhedron const is required by the visualisation system in order to cr
75. ur field Get a G4Field Manager 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 minimum step size below which it does not make sense to attempt to integrate 40 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 par ticle 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 G4 Transportation and re implement the part of GetAlongStepPhysicalInter actionLength that decides whe
76. xciteParticipants BuildStrings String aussianPt hooseX G4ExcitedString lt lt Concrete gt gt G4QuarkGluonStringModel Y GetStrings SGetWoundedNucleus CreateDiffractiveString CreateHardString CreateSoftString Figure 24 Level 4 implementation framework of the hadronic category of GEANT4 parton string aspect Purely Abstract G4VIntraNuclearTransportModel G4VParticleScatterer GetTimeTolnteraction Scatter G4ParticleScatterer Apply Y ourselt G4VKineticNucleon Propagate Decay Get4Momentum GetDefinition GetPosition G4V3DNucleus nit 1 GetCharge GetMassNumber G4Nucleon G4HadronKineticModel GetMass z SetTimeStep GetOuterRadius Pai pra StopTimeLoop GetNuclearRadius 1 wi articleType CheckPauliPrinciple BEZA GetNuclearRadius o T FindFragments DoLorentzBoost reYouHit UpdateKineticTrack DoLorentzBoost DoTimeStep DoLorentzContract on DoLorentzContract on DoTranslation V PStartLoop G4VFieldPropagation n Transport amp MirrorNucleons GetExcitationEnergy Init G4Fancy3DNucleus Figure 25 Level 4 implementation framework of the hadronic category of GEANT4 intra nuclear transport aspect 53

Geant4 User`s Guide - For Toolkit Developers

Contents

Download Pdf Manuals

Related Search

Related Contents