1 / 81

More on kernel

June 2005, Geant4 v7.0p01. More on kernel. Makoto Asai (SLAC) Geant4 Tutorial Course the 2nd Finnish Geant4 Workshop June 6-7 2005, Helsinki Institute of Physics. Contents. Detector sensitivity Track and step statuses Attaching user information to G4 classes Stacking mechanism

mingan
Télécharger la présentation

More on kernel

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. June 2005, Geant4 v7.0p01 More on kernel 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) More on Kernel - M.Asai (SLAC)

  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 user’s class objects, are collected in a G4Event object at the end of an event. More on Kernel - M.Asai (SLAC)

  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 More on Kernel - M.Asai (SLAC)

  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 user’s code (e.g. at EventAction). More on Kernel - M.Asai (SLAC)

  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. More on Kernel - M.Asai (SLAC)

  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 G4THitsCollection<MyDriftChamberHit> MyDriftChamberHitsCollection; More on Kernel - M.Asai (SLAC)

  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(G4HCofThisEvent*HCE); virtual G4bool ProcessHits(G4Step*aStep, G4TouchableHistory*ROhist); virtual void EndOfEvent(G4HCofThisEvent*HCE); private: MyDriftChamberHitsCollection * hitsCollection; G4int collectionID; }; More on Kernel - M.Asai (SLAC)

  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/analysis/A01 as an example. More on Kernel - M.Asai (SLAC)

  11. Implementation of Sensitive Detector - 1 MyDriftChamber::MyDriftChamber(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. More on Kernel - M.Asai (SLAC)

  12. Implementation of Sensitive Detector - 2 void MyDriftChamber::Initialize(G4HCofThisEvent*HCE) { if(collectionID<0) collectionID = GetCollectionID(0); hitsCollection = new MyDriftChamberHitsCollection (SensitiveDetectorName,collectionName[0]); HCE->AddHitsCollection(collectionID,hitsCollection); } • 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. More on Kernel - M.Asai (SLAC)

  13. Implementation of Sensitive Detector - 3 G4bool MyDriftChamber::ProcessHits (G4Step*aStep,G4TouchableHistory*ROhist) { MyDriftChamberHit* aHit = new MyDriftChamberHit(); ... // some set methods ... hitsCollection->insert(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). • Don’t forget to collect geometry information (e.g. copy number) from “PreStepPoint”. • Currently, returning boolean value is not used. More on Kernel - M.Asai (SLAC)

  14. Implementation of Sensitive Detector - 4 void MyDriftChamber::EndOfEvent(G4HCofThisEvent*HCE) {;} • 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. More on Kernel - M.Asai (SLAC)

  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. More on Kernel - M.Asai (SLAC)

  16. 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 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. More on Kernel - M.Asai (SLAC)

  17. Touchable • G4TouchableHistory has information of geometrical hierarchy of the point. G4Step* aStep; G4StepPoint* preStepPoint = aStep->GetPreStepPoint(); G4TouchableHistory* theTouchable = (G4TouchableHistory*)(preStepPoint->GetTouchable()); G4int copyNo = theTouchable->GetVolume()->GetCopyNo(); G4int motherCopyNo = theTouchable->GetVolume(1)->GetCopyNo(); G4int grandMotherCopyNo = theTouchable->GetVolume(2)->GetCopyNo(); G4ThreeVector worldPos = preStepPoint->GetPosition(); G4ThreeVector localPos = theTouchable->GetHistory() ->GetTopTransform().TransformPoint(worldPos); More on Kernel - M.Asai (SLAC)

  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. More on Kernel - M.Asai (SLAC)

  19. Defining a sensitive detector • Basic strategy G4LogicalVolume* myLogCalor = ……; G4VSensetiveDetector* pSensetivePart = new MyCalorimeter(“/mydet/calorimeter1”); G4SDManager* SDMan = G4SDManager::GetSDMpointer(); SDMan->AddNewDetector(pSensitivePart); myLogCalor->SetSensitiveDetector(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. More on Kernel - M.Asai (SLAC)

  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 G4SDManager::GetCollectionID(“detName/colName”); • The index table is also stored in G4Run. More on Kernel - M.Asai (SLAC)

  21. Usage of G4HCofThisEvent static int CHCID = -1; if(CHCID<0) G4SDManager::GetSDMpointer() ->GetCollectionID("myDet/calorimeter1/collection1"); G4HCofThisEvent* HCE = evt->GetHCofThisEvent(); MyCalorimeterHitsCollection* CHC = 0; if(HCE) {CHC = (MyCalorimeterHitsCollection*)(HCE->GetHC(CHCID));} if(CHC) { int n_hit = CHC->entries(); G4cout<<"Calorimeter has ”<<n_hit<<" hits."<<G4endl; for(int i1=0;i1<n_hit;i1++) { MyCalorimeterHit* aHit = (*CHC)[i1]; aHit->Print(); } } • This scheme can be adapted also for Digitization. cast More on Kernel - M.Asai (SLAC)

  22. Track and Step Statuses

  23. 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 won’t 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. More on Kernel - M.Asai (SLAC)

  24. Set the track status • In UserSteppingAction, user can change the status of a track. void MySteppingAction::UserSteppingAction (const G4Step * theStep) { G4Track* theTrack = theStep->GetTrack(); if(…) theTrack->SetTrackStatus(fSuspend); } • If a track is killed, physics quantities of the track (energy, charge, etc.) are not conserved but completely lost. More on Kernel - M.Asai (SLAC)

  25. 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 More on Kernel - M.Asai (SLAC)

  26. Attaching user information to some kernel classes

  27. 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 - G4VUserPrimaryParticleInformation • G4Region - G4VUserRegionInformation • User information class object is deleted when associated Geant4 class object is deleted. More on Kernel - M.Asai (SLAC)

  28. 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. More on Kernel - M.Asai (SLAC)

  29. 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->SetStoreTrajectory(true); } else { fpTrackingManager->SetStoreTrajectory(false); } } • If you want to use user-defined trajectory, object should be instantiated in this method and set to G4TrackingManager by SetTrajectory() method. More on Kernel - M.Asai (SLAC)

  30. Bookkeeping issues • Connection from G4PrimaryParticle to G4Track G4int G4PrimaryParticle::GetTrackID() • 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* G4DynamicParticle::GetPrimaryParticle() • 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. More on Kernel - M.Asai (SLAC)

  31. RE01TrackInformation PrimaryTrackID = 1SourceTrackID = 1 Examples/extended/runAndEvent/RE01 PrimaryTrackID = 1SourceTrackID = 1 PrimaryTrackID = 1SourceTrackID = 1 • An example for connecting G4PrimaryParticle, G4Track, hits and trajectories, by utilizing G4VUserTrackInformation and G4VUserRegionInformation. • 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 More on Kernel - M.Asai (SLAC)

  32. Trajectory of track6782 Tracker hits of track6782 Calorimeter hits of track6782 Examples/extended/runAndEvent/RE01 Energy deposition includes not only muon itself but also all secondary EM showers started inside the calorimeter. More on Kernel - M.Asai (SLAC)

  33. 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->preStepPoint->physicalVolume->logicalVolume->region-> regionInformation, you can easily identify in which region the current step belongs. • Don’t use volume name to identify. More on Kernel - M.Asai (SLAC)

  34. Cuts per region

  35. 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 More on Kernel - M.Asai (SLAC)

  36. Default Region Region B Region B Region B Region A C C Region B 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. More on Kernel - M.Asai (SLAC)

  37. World Volume - Default Region Root logical - Region A Root logical - Region B 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. More on Kernel - M.Asai (SLAC)

  38. Stack management

  39. 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. More on Kernel - M.Asai (SLAC)

  40. primary tracks End OfEvent Pop Classify NewStage Prepare New Event Reclassify Push Push Process One Track Pop Transfer Pop secondary and suspended tracks Push Deleted Transfer Push RIP 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 More on Kernel - M.Asai (SLAC)

  41. 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->ReClassify() • void PrepareNewEvent() • Invoked at the beginning of each event for resetting the classification scheme. More on Kernel - M.Asai (SLAC)

  42. 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. More on Kernel - M.Asai (SLAC)

  43. 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. More on Kernel - M.Asai (SLAC)

  44. 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". More on Kernel - M.Asai (SLAC)

  45. Event biasing

  46. 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. More on Kernel - M.Asai (SLAC)

  47. 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 More on Kernel - M.Asai (SLAC)

  48. Current features in Geant4 • Partial MARS migration • n, p, pi, K (< 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 More on Kernel - M.Asai (SLAC)

  49. I = 1.0 I = 2.0 W=0.5 W=0.5 W=1.0 P = 0.5 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 More on Kernel - M.Asai (SLAC)

  50. 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 More on Kernel - M.Asai (SLAC)

More Related