More on kernel

1
More on kernel
June 2005, Geant4 v7.0p01

• Makoto Asai (SLAC)
• Geant4 Tutorial Course
• the 2nd Finnish Geant4 Workshop
• June 6-7 2005, Helsinki Institute of Physics

2
Contents

• Detector sensitivity
• Track and step statuses
• Attaching user information to G4 classes
• Stacking mechanism
• Cuts per region
• Event biasing
• Fast simulation (Shower parameterization)

3
Detector Sensitivity
4
Sensitive detector and Hit

• Each Logical Volume can have a pointer to a
  sensitive detector.
• Then this volume becomes sensitive.
• Hit is a snapshot of the physical interaction of
  a track or an accumulation of interactions of
  tracks in the sensitive region of your detector.
• A sensitive detector creates hit(s) using the
  information given in G4Step object. The user has
  to provide his/her own implementation of the
  detector response.
• UserSteppingAction class should NOT do this.
• Hit objects, which are still the users class
  objects, are collected in a G4Event object at the
  end of an event.

5
Detector sensitivity

• A sensitive detector either
• constructs one or more hit objects or
• accumulates values to existing hits
• using information given in a G4Step object.
• Note that you must get the volume information
  from the PreStepPoint.

Boundary
End of step point
Step
Begin of step point
6
Digitizer module and digit

• Digit represents a detector output (e.g. ADC/TDC
  count, trigger signal, etc.).
• Digit is created with one or more hits and/or
  other digits by a user's concrete implementation
  derived from G4VDigitizerModule.
• In contradiction to the sensitive detector which
  is accessed at tracking time automatically, the
  digitize() method of each G4VDigitizerModule must
  be explicitly invoked by the users code (e.g. at
  EventAction).

7
Hit class

• Hit is a user-defined class derived from G4VHit.
• You can store various types information by
  implementing your own concrete Hit class. For
  example
• Position and time of the step
• Momentum and energy of the track
• Energy deposition of the step
• Geometrical information
• or any combination of above
• Hit objects of a concrete hit class must be
  stored in a dedicated collection which is
  instantiated from G4THitsCollection template
  class.
• The collection will be associated to a G4Event
  object via G4HCofThisEvent.
• Hits collections are accessible
• through G4Event at the end of event.
• to be used for analyzing an event
• through G4SDManager during processing an event.
• to be used for event filtering.

8
Implementation of Hit class

• include "G4VHit.hh"
• class MyDriftChamberHit public G4VHit
• public
• MyDriftChamberHit(some_arguments)
• virtual MyDriftChamberHit()
• virtual void Draw()
• virtual void Print()
• private
• // some data members
• public
• // some set/get methods
• include G4THitsCollection.hh
• typedef G4THitsCollectionltMyDriftChamberHitgt
• MyDriftChamberHitsCollection

9
Sensitive Detector class

• Sensitive detector is a user-defined class
  derived from G4VSensitiveDetector.
• include "G4VSensitiveDetector.hh"
• include "MyDriftChamberHit.hh"
• class G4Step
• class G4HCofThisEvent
• class MyDriftChamber public G4VSensitiveDetector
  
• public
• MyDriftChamber(G4String name)
• virtual MyDriftChamber()
• virtual void Initialize(G4HCofThisEventHCE)
  
• virtual G4bool ProcessHits(G4StepaStep,
• G4TouchableHistoryROhi
  st)
• virtual void EndOfEvent(G4HCofThisEventHCE)
  
• private
• MyDriftChamberHitsCollection
  hitsCollection
• G4int collectionID

10
Sensitive detector

• A tracker detector typically generates a hit for
  every single step of every single (charged)
  track.
• A tracker hit typically contains
• Position and time
• Energy deposition of the step
• Track ID
• A calorimeter detector typically generates a hit
  for every cell, and accumulates energy deposition
  in that cell for all steps of all tracks.
• A calorimeter hit typically contains
• Sum of deposited energy
• Cell ID
• You can instantiate more than one objects for one
  sensitive detector class. Each object should have
  its unique detector name.
• For example, each of two sets of drift chambers
  can have their dedicated sensitive detector
  objects. But, the functionalities of them are
  exactly the same to each other and thus they can
  share the same class. See examples/extended/analys
  is/A01 as an example.

11
Implementation of Sensitive Detector - 1

• MyDriftChamberMyDriftChamber(G4String
  detector_name)
• G4VSensitiveDetector(detector_name
  ),
• collectionID(-1)
• collectionName.insert(collection_name")
• In the constructor, define the name of the hits
  collection which is handled by this sensitive
  detector
• In case your sensitive detector generates more
  than one kinds of hits (e.g. anode and cathode
  hits separately), define all collection names.

12
Implementation of Sensitive Detector - 2

• void MyDriftChamberInitialize(G4HCofThisEventHC
  E)
• if(collectionIDlt0) collectionID
  GetCollectionID(0)
• hitsCollection new MyDriftChamberHitsCollectio
  n
• (SensitiveDetectorName,collectionName0)
  
• HCE-gtAddHitsCollection(collectionID,hitsCollecti
  on)
• Initialize() method is invoked at the beginning
  of each event.
• Get the unique ID number for this collection.
• GetCollectionID() is a heavy operation. It should
  not be used for every events.
• GetCollectionID() is available after this
  sensitive detector object is registered to
  G4SDManager. Thus, this method cannot be used in
  the constructor of this detector class.
• Instantiate hits collection(s) and attach it/them
  to G4HCofThisEvent object given in the argument.
• In case of calorimeter-type detector, you may
  also want to instantiate hits for all calorimeter
  cells with zero energy depositions, and insert
  them to the collection.

13
Implementation of Sensitive Detector - 3

• G4bool MyDriftChamberProcessHits
• (G4StepaStep,G4TouchableHistoryROhist)
• MyDriftChamberHit aHit new
  MyDriftChamberHit()
• ...
• // some set methods
• ...
• hitsCollection-gtinsert(aHit)
• return true
• This ProcessHits() method is invoked for every
  steps in the volume(s) where this sensitive
  detector is assigned.
• In this method, generate a hit corresponding to
  the current step (for tracking detector), or
  accumulate the energy deposition of the current
  step to the existing hit object where the current
  step belongs to (for calorimeter detector).
• Dont forget to collect geometry information
  (e.g. copy number) from PreStepPoint.
• Currently, returning boolean value is not used.

14
Implementation of Sensitive Detector - 4

• void MyDriftChamberEndOfEvent(G4HCofThisEventHC
  E)
• This method is invoked at the end of processing
  an event.
• It is invoked even if the event is aborted.
• It is invoked before UserEndOfEventAction.

15
Touchable

• As mentioned already, G4Step has two G4StepPoint
  objects as its starting and ending points. All
  the geometrical information of the particular
  step should be taken from PreStepPoint.
• Geometrical information associated with G4Track
  is basically same as PostStepPoint.
• Each G4StepPoint object has
• Position in world coordinate system
• Global and local time
• Material
• G4TouchableHistory for geometrical information
• G4TouchableHistory object is a vector of
  information for each geometrical hierarchy.
• copy number
• transformation / rotation to its mother
• Since release 4.0, handles (or smart-pointers) to
  touchables are intrinsically used. Touchables are
  reference counted.

16
Copy number

• Suppose a calorimeter is made of 4x5 cells.
• and it is implemented by two levels of replica.
• In reality, there is only one physical volume
  object for each level. Its position is
  parameterized by its copy number.
• To get the copy number of each level, suppose
  what happens if a step belongs to two cells.

CopyNo 0
CopyNo 1
CopyNo 2
CopyNo 3

• Remember geometrical information in G4Track is
  identical to "PostStepPoint".
• You cannot get the collect copy number for
  "PreStepPoint" if you directly access to the
  physical volume.
• Use touchable to get the proper copy number,
  transform matrix, etc.

17
Touchable

• G4TouchableHistory has information of geometrical
  hierarchy of the point.
• G4Step aStep
• G4StepPoint preStepPoint aStep-gtGetPreStepPoint
  ()
• G4TouchableHistory theTouchable
• (G4TouchableHistory)(preStepPoint-gtGetTouchab
  le())
• G4int copyNo theTouchable-gtGetVolume()-gtGetCopyN
  o()
• G4int motherCopyNo
• theTouchable-gtGetVolume(1)-gtGetCopyN
  o()
• G4int grandMotherCopyNo
• theTouchable-gtGetVolume(2)-gtGetCopyN
  o()
• G4ThreeVector worldPos preStepPoint-gtGetPosition
  ()
• G4ThreeVector localPos theTouchable-gtGetHistory(
  )
• -gtGetTopTransform().TransformPoint(worldPos)

18
Readout geometry

• In some cases of most complicated geometries, it
  is not easy to define volume boundaries
  corresponding to the readout segmentation.
• Readout geometry is a virtual and artificial
  geometry which can be defined in parallel to the
  real detector geometry.
• Readout geometry is optional. May have more than
  one.
• Each one should be associated to a sensitive
  detector.
• Note that a step is not limited by the boundary
  of readout geometry.

19
Defining a sensitive detector

• Basic strategy
• G4LogicalVolume myLogCalor
• G4VSensetiveDetector pSensetivePart
• new MyCalorimeter(/mydet/calorimeter1)
• G4SDManager SDMan G4SDManagerGetSDMpointer()
  
• SDMan-gtAddNewDetector(pSensitivePart)
• myLogCalor-gtSetSensitiveDetector(pSensetivePart)
• Each detector object must have a unique name.
• Some logical volumes can share one detector
  object.
• More than one detector objects can be
  instantiated from one detector class with
  different detector name.
• One logical volume cannot have more than one
  detector objects. But, one detector object can
  generate more than one kinds of hits.
• e.g. a drift chamber class may generate anode and
  cathode hits separately.

20
G4HCofThisEvent

• A G4Event object has a G4HCofThisEvent object at
  the end of (successful) event processing.
  G4HCofThisEvent object stores all hits
  collections made within the event.
• Pointer(s) may be NULL if collection(s) are not
  created in the particular event.
• Hits collections are stored by pointers of
  G4VHitsCollection base class. Thus, you have to
  cast them to types of individual concrete
  classes.
• The index number of a Hits collection is unique
  and stable for a run and can be obtained by
  G4SDManagerGetCollectionID(detName/colName)
• The index table is also stored in G4Run.

21
Usage of G4HCofThisEvent

• static int CHCID -1
• if(CHCIDlt0) G4SDManagerGetSDMpointer()
• -gtGetCollectionID("myDet/calorimeter1/collectio
  n1")
• G4HCofThisEvent HCE evt-gtGetHCofThisEvent()
• MyCalorimeterHitsCollection CHC 0
• if(HCE)
• CHC (MyCalorimeterHitsCollection)(HCE-gtGetHC(C
  HCID))
• if(CHC)
• int n_hit CHC-gtentries()
• G4coutltlt"Calorimeter has ltltn_hitltlt"
  hits."ltltG4endl
• for(int i10i1ltn_hiti1)
• MyCalorimeterHit aHit (CHC)i1
• aHit-gtPrint()
• This scheme can be adapted also for Digitization.

cast
22
When to invoke GetCollectionID()?

• Which is the better place to invoke
  G4SDManagerGetCollectionID() in a user event
  action class, in its constructor or in the
  BeginOfEventAction()?
• It actually depends on the user's application.
• Note that construction of sensitive detectors
  (and thus registration of their hits collections
  to SDManager) takes place when the user issues
  RunManagerInitialize(), and thus the users
  geometry is constructed.
• In case user's EventAction class should be
  instantiated before RunmanagerInitialize(),
  GetCollectionID() should not be in the
  constructor of EventAction.
• While, if the user has nothing to do to Geant4
  before RunManagerInitialize(), this initialize
  method can be hard-coded in the main() before the
  instantiation of EventAction (e.g. exampleA01),
  so that GetCollectionID() could be in the
  constructor.

23
Track and Step Statuses
24
Track status

• At the end of each step, according to the
  processes involved, the state of a track may be
  changed.
• The user can also change the status in
  UserSteppingAction.
• Statuses shown in yellow are artificial, i.e.
  Geant4 kernel wont set them, but the user can
  set.
• fAlive
• Continue the tracking.
• fStopButAlive
• The track has come to zero kinetic energy, but
  still AtRest process to occur.
• fStopAndKill
• The track has lost its identity because it has
  decayed, interacted or gone beyond the world
  boundary.
• Secondaries will be pushed to the stack.
• fKillTrackAndSecondaries
• Kill the current track and also associated
  secondaries.
• fSuspend
• Suspend processing of the current track and push
  it and its secondaries to the stack.
• fPostponeToNextEvent
• Postpone processing of the current track to the
  next event.
• Secondaries are still being processed within the
  current event.

25
Set the track status

• In UserSteppingAction, user can change the status
  of a track.
• void MySteppingActionUserSteppingAction
• (const G4Step theStep)
• G4Track theTrack theStep-gtGetTrack()
• if() theTrack-gtSetTrackStatus(fSuspend)
• If a track is killed, physics quantities of the
  track (energy, charge, etc.) are not conserved
  but completely lost.

26
Step status

• Step status is attached to G4StepPoint to
  indicate why that particular step was determined.
• Use PostStepPoint to get the status of this
  step.
• PreStepPoint has the status of the previous
  step.
• fWorldBoundary
• Step reached the world boundary
• fGeomBoundary
• Step is limited by a geometry boundary
• fAtRestDoItProc, fAlongStepDoItProc,
  fPostStepDoItProc
• Step is limited by a AtRest, AlongStep or
  PostStep process
• fUserDefinedLimit
• Step is limited by the user Step limit in the
  logical volume
• fExclusivelyForcedProc
• Step is limited by an exclusively forced PostStep
  process
• fUndefined
• Step not defined yet
• If you want to identify the first step in a
  volume, pick fGeomBoudary status in PreStepPoint.
  
• If you want to identify a step getting out of a
  volume, pick fGeomBoundary status in PostStepPoint

27
Attaching user information to some kernel classes
28
Attaching user information

• Abstract classes
• User can use his/her own class derived from the
  provided base class
• G4Run, G4VHit, G4VDigit, G4VTrajectory,
  G4VTrajectoryPoint
• Concrete classes
• User can attach a user information class object
• G4Event - G4VUserEventInformation
• G4Track - G4VUserTrackInformation
• G4PrimaryVertex - G4VUserPrimaryVertexInformation
• G4PrimaryParticle - G4VUserPrimaryParticleInformat
  ion
• G4Region - G4VUserRegionInformation
• User information class object is deleted when
  associated Geant4 class object is deleted.

29
Trajectory and trajectory point

• Trajectory and trajectory point class objects
  persist until the end of an event.
• And most likely stored to disk as "simulation
  truth"
• G4VTrajectory is the abstract base class to
  represent a trajectory, and G4VTrajectoryPoint is
  the abstract base class to represent a point
  which makes up the trajectory.
• In general, trajectory class is expected to have
  a vector of trajectory points.
• Geant4 provides G4Trajectoy and G4TrajectoryPoint
  concrete classes as defaults. These classes keep
  only the most common quantities.
• If the user wants to keep some additional
  information and/or wants to change the drawing
  style of a trajectory, he/she is encouraged to
  implement his/her own concrete classes.

30
Creation of trajectories

• Naïve creation of trajectories occasionally
  causes a memory consumption concern, especially
  for high energy EM showers.
• In UserTrackingAction, you can switch on/off the
  creation of a trajectory for the particular
  track.
• void MyTrackingAction
• PreUserTrackingAction(const G4Track
  aTrack)
• if(...)
• fpTrackingManager-gtSetStoreTrajectory(true)
  
• else
• fpTrackingManager-gtSetStoreTrajectory(false)
  
• If you want to use user-defined trajectory,
  object should be instantiated in this method and
  set to G4TrackingManager by SetTrajectory()
  method.

31
Bookkeeping issues

• Connection from G4PrimaryParticle to G4Track
• G4int G4PrimaryParticleGetTrackID()
• Returns the track ID if this primary particle had
  been converted into G4Track, otherwise -1.
• Both for primaries and pre-assigned decay
  products
• Connection from G4Track to G4PrimaryParticle
• G4PrimaryParticle G4DynamicParticleGetPrimaryPa
  rticle()
• Returns the pointer of G4PrimaryParticle object
  if this track was defined as a primary or a
  pre-assigned decay product, otherwise null.
• G4VUserPrimaryVertexInformation,
  G4VUserPrimaryParticleInformation and
  G4VUserTrackInformation can be utilized for
  storing additional information.
• Information in UserTrackInformation should be
  then copied to user-defined trajectory class, so
  that such information is kept until the end of
  the event.

32
Examples/extended/runAndEvent/RE01
PrimaryTrackID 1SourceTrackID 1
PrimaryTrackID 1SourceTrackID 1

• An example for connecting G4PrimaryParticle,
  G4Track, hits and trajectories, by utilizing
  G4VUserTrackInformation and G4VUserRegionInformati
  on.
• SourceTrackID means the ID of a track
  which gets into calorimeter.
• PrimaryTrackID is copied to
  UserTrackInformation of daughter
  tracks.
• SourceTrackID is updated for secondaries born in
  tracker, while just copied in calorimeter.

PrimaryTrackID 1SourceTrackID 1
PrimaryTrackID 1SourceTrackID 4
PrimaryTrackID 1SourceTrackID 4
PrimaryTrackID 1SourceTrackID 3
PrimaryTrackID 1SourceTrackID 4
PrimaryTrackID 1SourceTrackID 4
PrimaryTrackID 2SourceTrackID 2
33
Examples/extended/runAndEvent/RE01
Energy deposition includes not only muon itself
but also all secondary EM showers started inside
the calorimeter.
34
RE01RegionInformation

• This example RE01 has three regions, i.e. default
  world region, tracker region and calorimeter
  region.
• Each region has its unique object of
  RE01RegionInformation class.
• class RE01RegionInformation public
  G4VUserRegionInformation
• public
• G4bool IsWorld() const
• G4bool IsTracker() const
• G4bool IsCalorimeter() const
• Through step-gtpreStepPoint-gtphysicalVolume-gtlogica
  lVolume-gtregion-gt regionInformation, you can
  easily identify in which region the current step
  belongs.
• Dont use volume name to identify.

35
Cuts per region
36
Cuts per Region

• Geant4 has had a unique production threshold
  (cut) expressed in length (i.e. minimum range
  of secondary).
• For all volumes
• Possibly different for each particle.
• Yet appropriate length scales can vary greatly
  between different areas of a large detector
• E.g. a vertex detector (5 mm) and a muon detector
  (2.5 cm).
• Having a unique (low) cut can create a
  performance penalty.
• Requests from ATLAS, BABAR, CMS, LHCb, , to
  allow several cuts
• Globally or per particle
• New functionality,
• enabling the tuning of production thresholds at
  the level of a sub-detector, i.e. region.
• Cuts are applied only for gamma, electron and
  positron and only for processes which have
  infrared divergence.
• Full release in Geant4 5.1 (end April, 2003)
• Comparable run-time performance

37
Region

• Introducing the concept of region.
• Set of geometry volumes, typically of a
  sub-system
• barrel end-caps of the calorimeter
• Deep areas of support structures can be a
  region.
• Or any group of volumes
• A set of cuts in range is associated to a region
• a different range cut for each particle among
  gamma, e-, e is allowed in a region.

38
Region and cut

• Each region has its unique set of cuts.
• World volume is recognized as the default region
  and the default cuts defined in Physics list are
  used for it.
• User is not allowed to define a region to the
  world volume or a cut to the default region.
• A logical volume becomes a root logical volume
  once it is assigned to a region.
• All daughter volumes belonging to the root
  logical volume share the same region (and cut),
  unless a daughter volume itself becomes to
  another root.
• Important restriction
• No logical volume can be shared by more than one
  regions, regardless of root volume or not.

39
Stack management
40
Track stacks in Geant4

• By default, Geant4 has three track stacks.
• "Urgent", "Waiting" and "PostponeToNextEvent"
• Each stack is a simple "last-in-first-out" stack.
  
• User can arbitrary increase the number of stacks.
• ClassifyNewTrack() method of UserStackingAction
  decides which stack each newly storing track to
  be stacked (or to be killed).
• By default, all tracks go to Urgent stack.
• A Track is popped up only from Urgent stack.
• Once Urgent stack becomes empty, all tracks in
  Waiting stack are transferred to Urgent stack.
• And NewStage() method of UsetStackingAction is
  invoked.
• Utilizing more than one stacks, user can control
  the priorities of processing tracks without
  paying the overhead of "scanning the highest
  priority track" which was the only available way
  in Geant3.
• Proper selection/abortion of tracks/events with
  well designed stack management provides
  significant efficiency increase of the entire
  simulation.

41
Stacking mechanism
User Stacking Action
Temporary Stack
Event Manager
Urgent Stack
Urgent Stack
Stacking Manager
Waiting Stack
Waiting Stack
Tracking Manager
Postpone To Next Event Stack
Postpone To Next Event Stack
42
G4UserStackingAction

• User has to implement three methods.
• G4ClassificationOfNewTrack ClassifyNewTrack(const
  G4Track)
• Invoked every time a new track is pushed to
  G4StackManager.
• Classification
• fUrgent - pushed into Urgent stack
• fWaiting - pushed into Waiting stack
• fPostpone - pushed into PostponeToNextEvent stack
• fKill - killed
• void NewStage()
• Invoked when Urgent stack becomes empty and all
  tracks in Waiting stack are transferred to Urgent
  stack.
• All tracks which have been transferred from
  Waiting stack to Urgent stack can be reclassified
  by invoking stackManager-gtReClassify()
• void PrepareNewEvent()
• Invoked at the beginning of each event for
  resetting the classification scheme.

43
ExN04StackingAction

• ExampleN04 has simplified collider detector
  geometry and event samples of Higgs decays into
  four muons.
• Stage 0
• Only primary muons are pushed into Urgent stack
  and all other primaries and secondaries are
  pushed into Waiting stack.
• All of four muons are tracked without being
  bothered by EM showers caused by delta-rays.
• Once Urgent stack becomes empty (i.e. end of
  stage 0), number of hits in muon counters are
  examined.
• Proceed to next stage only if sufficient number
  of muons passed through muon counters. Otherwise
  the event is aborted.

44
ExN04StackingAction

• Stage 1
• Only primary charged particles are pushed into
  Urgent stack and all other primaries and
  secondaries are pushed into Waiting stack.
• All of primary charged particles are tracked
  until they reach to the surface of calorimeter.
  Tracks reached to the calorimeter surface are
  suspended and pushed back to Waiting stack.
• All charged primaries are tracked in the tracking
  region without being bothered by the showers in
  calorimeter.
• At the end of stage 1, isolation of muon tracks
  is examined.

45
ExN04StackingAction

• Stage 2
• Only tracks in "region of interest" are pushed
  into Urgent stack and all other tracks are
  killed.
• Showers are calculated only inside of "region of
  interest".

46
Event biasing
47
Event biasing in Geant4

• Event biasing (variance reduction) techniques are
  a vital requirement for many applications
• These feature could be utilized by many
  application fields such as
• Shielding
• Radiation environment assessment
• Dosimetry
• Since Geant4 is a toolkit and also all source
  code is open, the user can do whatever he/she
  wants.
• Capable users in experiments/institutions created
  their own implementations of event biasing.
• Yet it is more convenient for user if Geant4
  itself provides most commonly used event biasing
  techniques.

48
Event biasing techniques

• Production cuts / threshold
• This is a biasing technique most popular for
  many applications
• Geometry based biasing
• Importance weighting for volume/region
• Duplication or sudden death of tracks
• Leading particle biasing
• Taking only the most energetic (or most
  important) secondary
• Primary event biasing
• Biasing primary events and/or primary particles
  in terms of type of event, momentum distribution,
  etc.
• Forced interaction
• Force a particular interaction, e.g. within a
  volume
• Enhanced process or channel
• Increasing cross section for a process
• Physics based biasing
• Biasing secondary production in terms of particle
  type, momentum distribution, cross-section, etc.
• ? Weight on Track / Event

49
Current features in Geant4

• Partial MARS migration
• n, p, pi, K (lt 5 GeV)
• Since Geant4 0.0
• General particle source module
• Primary particle biasing
• Since Geant4 3.0
• Radioactive decay module
• Physics process biasing in terms of decay
  products and momentum distribution
• Since Geant4 3.0
• Geometry based biasing
• Weight associating with real volume or artificial
  volume
• Since Geant4 4.2
• Weight cutoff and weight window
• Since Geant4 5.2
• Cross-section biasing and leading particle
  biasing for hadronic processes
• Since Geant4 7.0

50
Geometrical importance biasing

• Define importance for each geometrical region
• Splitting a track,
• Eg creating two particles with half the weight
  if it moves into volume with double importance
  value.
• Russian-roulette in opposite direction.
• Scoring particle flux with weights
• At the surface of volumes

51
Using importance biasing

• Decide whether to bias in mass geometry, or in
  a dedicated parallel geometry (importance
  geometry).
• Assign an importance value to all volumes in this
  geometry
• The importance is a number (double)
• Register the processes for importance biasing
  (and scoring, optionally) to each particle type
  (eg neutron, gamma, proton, )
• Examples show easy ways to do this.
• Caveats
• World of importance geometry must overlap
  exactly with mass world
• Biasing and scoring of charged particles in a
  field is not yet supported
• More details
• Users can choose their importance sampling
  algorithm,
• Or accept the default one (equal weight).
• For customization further information see
  Geant4 User's Guide for Application Developers,
  Section 3.7

52
Biasing example B01

• Examples demonstrating the use of importance
  biasing and scoring can be found in
  examples/extended/biasing
• B01
• Shows the importance sampling and scoring in the
  mass (tracking) geometry
• Option to show weight window
• Geometry is 80 cm high concrete cylinder divided
  into 18 slabs
• Importance values assigned to 18 concrete slabs
  in the detector construction - for simplicity.
• The G4Scorer is used for the scoring
• Top level class uses the frame work provided for
  scoring.

53
Example biasing B02

• Show how to use
• importance sampling in a parallel geometry and
• a customized scoring making use of the scoring
  framework.
• A simple mass geometry consists of a 180 cm high
  concrete cylinder
• A parallel geometry is created to hold importance
  values for slabs of width 10cm and for scoring.
• Note The parallel world volume must overlap the
  mass world volume
• The radii of the slabs is larger than the radius
  of the concrete cylinder in the mass geometry.
• The importance value is assigned to each
  G4GeometryCell
• To do this, pairs of G4GeometryCell and
  importance values are stored in the importance
  store.
• The scoring uses the G4CellSCorer and one
  customized scorer for the last slab.

54
Example B03

• Uses Geant4 importance sampling and scoring
  through python.
• It creates a simple histogram.
• It demonstrates how to use a customized scorer
  and importance sampling in combination with a
  scripting language, python.
• Geant4 code is executed from a python session.
• Note the swig package is used to create python
  shadow classes and to generate the code necessary
  to use the Geant4 libraries from a python
  session.
• It can be built and run using the PI
  implementation of AIDA
• For this see http//cern.ch/PI.
• At the end a histogram called "trackentering.hbook
  " is create.

55
The Weight Window Technique

• The weight window technique is a weight-based
  algorithm generally used together with other
  techniques as an alternative to importance
  sampling
• It applies splitting and Russian roulette
  depending on space (cells) and energy
• user defines weight windows in contrast to
  defining importance values as in importance
  sampling
• It checks the value of the particle weight
• Comparing it to a window of weights defined for
  the current energy-space cell.
• Doing splitting or roulette in case if it is
  outside, resulting in 0 or more particles
  inside the window.
• apply in combination with other techniques such
  as cross-section biasing, leading particle and
  implicit capture, or combinations of these.

• A weight window may be specified for every cell
  and for several energy regions space-energy cell
  .

56
Leading particle biasing

• Simulating a full shower is an expensive
  calculation.
• Instead of generating a full shower, trace only
  the most energetic secondary.
• Other secondary particles are immediately killed
  before being stacked.
• Convenient way to roughly estimate, e.g. the
  thickness of a shield.
• Of course, physical quantities such as energy are
  not conserved for each event.

57
Scoring

• Scoring is provided by a framework and is done
  according to particle type.
• It is possible to score particles of different
  types into the same scorer. The framework may
  also be easily used for customized scoring.
• Scoring may be applied to a mass or a parallel
  geometry. It is done with an object generically
  called a scorer using a sampler.
• The scorer receives the information about every
  step taken by a particle of chosen type. This
  information consists a G4Step and a
  G4GeometryCellStep (created for scoring and
  importance sampling).
• G4GeometryCellStep provides information about the
  previous and current "cell" of the particle
  track.
• A "scorer" class derives from the interface
  G4VScorer. Users may create customized "scorers"
  or use the standard scoring.

58
Plans of event biasing in Geant4

• Cross-section biasing for physics processes
• General geometrical weight field
• In continuous process for geometrical, angular,
  energy biasing and weight window.
• First implementation of weight-window biasing
  option was introduced with Geant4 6.0.
• Another biasing options are under study.
• Other scoring options rather than surface flux
  counting which is currently supported are under
  study.
• ?Users contribution is welcome.

59
Fast simulation(shower parameterization)
60
Fast simulation - Generalities

• Fast Simulation, also called as shower
  parameterization, is a shortcut to the "ordinary"
  tracking.
• Fast Simulation allows you to take over the
  tracking and implement your own "fast" physics
  and detector response.
• The classical use case of fast simulation is the
  shower parameterization where the typical several
  thousand steps per GeV computed by the tracking
  are replaced by a few ten of energy deposits per
  GeV.
• Parameterizations are generally experiment
  dependent. Geant4 provides a convenient
  framework.

61
Parameterization features

• Parameterizations take place in an envelope. This
  is typically a mother volume of a sub-system or
  of a major module of such a sub-system.
• Parameterizations are often dependent to
  particle types and/or may be applied only to some
  kinds of particles.
• They are often not applied in complicated regions.

62
Models and envelope

• Concrete models are bound to the envelope through
  a G4FastSimulationManager object.
• This allows several models to be bound to one
  envelope.
• The envelope is simply a G4LogicalVolume which
  has G4FastSimulationManager.
• All its granddaughters will be sensitive to
  the parameterizations.
• A model may returns back to the "ordinary"
  tracking the new state of G4Track after
  parameterization (alive/killed, new position, new
  momentum, etc.) and eventually adds secondaries
  (e.g. punch-through) created by the
  parameterization.

 envelope  (G4LogicalVolume)
G4FastSimulationManager
ModelForElectrons
ModelForPions
63
Fast Simulation

• The Fast Simulation components are indicated in
  white.

 envelope  (G4LogicalVolume)
G4FastSimulationManager
ModelForElectrons
Placements
ModelForPions

• When the G4Track comes in an envelope,
• the G4FastSimulationManagerProcess
• looks for a G4FastSimulationManager.
• If one exists, at the beginning of each step in
  the envelope, each model is asked for a trigger.
• In case a trigger is issued, the model is applied
  at the point the G4track is.
• Otherwise, the tracking proceeds with a normal
  tracking.

G4Track
G4ProcessManager
Process xxx
Multiple Scattering
G4FastSimulationManagerProcess
G4Transportation
64
G4FastSimulationManagerProcess

• The G4FastSimulationManagerProcess is a process
  providing the interface between the tracking and
  the fast simulation.
• It has to be set to the particles to be
  parameterized
• The process ordering must be the following
• n-3
• n-2 Multiple Scattering
• n-1 G4FastSimulationManagerProcess
• n G4Transportation
• It can be set as a discrete process or it must be
  set as a continuous discrete process if using
  ghost volumes.

65
Ghost Volume

• Ghost volumes allow to define envelopes
  independent to the volumes of the tracking
  geometry.
• For example, this allows to group together
  electromagnetic and hadronic calorimeters for
  hadron parameterization or to define envelopes
  for imported geometries which do not have a
  hierarchical structure.
• In addition, Ghost volumes can be sensitive to
  particle type, allowing to define envelops
  individually to particle types.
• Ghost Volume of a given particle type is placed
  as a clone of the world volume for tracking.
• This is done automatically by G4GlobalFastSimulati
  onManager.
• The G4FastSimulationManagerProcess provides the
  additional navigation inside a ghost geometry.
  This special navigation is done transparently to
  the user.

66
User support processes in Geant4
67
User Support

• Geant4 Collaboration offers extensive user
  supports.
• Users workshops
• Tutorial courses
• HyperNews and mailing list
• Bug reporting system
• Requirements tracking system
• Daily private communications
• Technical Forum
• http//cern.ch/geant4/

68
Geant4 users workshop

• Users workshops were held or are going to be held
  hosted by several institutes for various user
  communities.
• KEK - Dec.2000, Jul.2001, Mar.2002, Jul.2002,
  Mar.2003, Jul.2003, Jul.2004, Jan.2005
• SLAC - Feb.2002
• Spain (supported by INFN) - Jul.2002
• CERN - Nov.2002
• NASA/ESA/Vanderbilt - Jan.2003, May.2004,
  Oct.2005
• Helsinki - Oct.2003, Jun.2005
• Local workshops of one or two days were held or
  are planned at several places.

69
Geant4 tutorials / lectures

• In addition to the users workshops, many tutorial
  courses and lectures with some discussion time
  slots were held for various user communities.
• CERN School of Computing
• Italian National School for HEP/Nuclear
  Physicists
• MC2000
• MCNEG workshop
• IEEE NSS/MIC
• KEK, SLAC, DESY, FNAL, INFN, Frascati,
  Karolinska, GranSasso, etc.
• ATLAS, CMS, LHCb
• Tutorials/lectures at universities
• Italy - Genoa, Bologna, Udine, Roma, Trieste
• U.K. - Imperial
• U.S. - Vanderbilt
• Geant4 collaboration is happy to offer tutorial
  courses if requested.
• SLAC Geant4 team is offering tutorial courses
  regularly.
• http//geant4.slac.stanford.edu/

70
HyperNews

• HyperNews system was set up in April 2001

71
HyperNews

• 22 categories
• Not only user-developer, but also user-user
  information exchanges are quite intensive.

72
HyperNews is quite active
73
Some postings are novice
74
Some are excellent users contribution
75
Technical Forum

• In the Technical Forum, the Geant4 Collaboration,
  its user community and resource providers
  discuss
• major user and developer requirements, user and
  developer priorities, software implementation
  issues, prioritized plans, physics validation
  issues, user support issues
• The Technical Forum is open to all interested
  parties
• To be held at least 4 times per year (in at least
  two locales)
• First Technical Forum at TRIUMF in September
  2003, followed by forum meetings at various
  places.
• The purpose of the forum is to
• Achieve, as much as possible, a mutual
  understanding of the needs and plans of users and
  developers.
• Provide the Geant4 Collaboration with the
  clearest possible understanding of the needs of
  its users.
• Promote the exchange of information about physics
  validation performed by Geant4 Collaborators and
  Geant4 users.
• Promote the exchange of information about user
  support provided by Geant4 Collaborators and
  Geant4 user communities.

76
SLAC Geant4 team
77
SLAC Computing Services (SCS)
Scientific Computing and Computing Services (SCCS)
78
Physics Experiment Support Group

• Objectives
• Support software developments and maintenances
  for the experiments SLAC is hosting
• Participate nation-wide and international
  collaborating research and development activities
  of HEP software
• On-line team
• Database team
• Off-line team

79
Vis Analysis Tools for HEP
http//www.freehep.org

• Experiment Independent
• Abstract Interfaces
• Component Architecture

• Experiment or collaboration choose the
  interfaces end users choose the desktop tool
• Based on well-defined, flexible, language neutral
  interfaces

BaBar, GLAST,LCD, Geant4
Data Analysis Visualization
Event Display
HepRep
AIDA
Abstract Interfaces
IceCube, CLEO
WIRED
Mark Dönszelmann Tony Johnson Joseph Perl Victor
Serbo Max Turri
FRED
80
Geant4
81
http//geant4.slac.stanford.edu/
82
(No Transcript)