Geometrical Event biasing and Variance Reduction – Talk 1

1. Geometrical Event biasing and Variance Reduction – Talk 1 • Geometrical Event Biasing - Overview • User Requirements – as documented • Use Cases • Limitations of current implementation • Parallel Navigation • Scoring – (in)dependency • Examples • Summary Alex Howard, CERN Event Biasing Mini-Workshop, SLAC 19th March 2007

2. Geometric Biasing The purpose of geometry based event biasing is to save computing time by sampling less often the particle histories entering “less important” geometry regions, and more often in more “important” regions. * Importance sampling technique * Weight window technique

3. Importance sampling technique • Importance sampling acts on particles crossing boundaries between “importance cells”. • The action taken depends on the importance value assigned to the cell. • In general, a track is either split or plays Russian roulette at the geometrical boundary depending on the importance value assigned to the cell. I=1 I=2 • Survival probability (P) is defined by the ratio of importance value. P = Ipost / Ipre • The track weight is changed to W/P. W=0.5 W=1 W=0.5 P = 2 • Splitting a track ( P > 1 ) • E.g. creating two particles with half the ‘weight’ if it moves into volume with double importance value. P = 0.5 X W=1 W=0.5 • Russian-roulette (P < 1 ) in opposite direction • E.g. Kill particles according to the survival probability (1 - P).

4. 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 A weight window may be specified for every cell and for several energy regions: space-energy cell . The Weight Window Technique Upper weight Upper Energy Survival weight Upper Energy Lower weight E Split Lower weight Lower Weight D C B Kill/Survive A Lower weight • Apply in combination with other techniques such as cross-section biasing, leading particle and implicit capture, or combinations of these.

5. Original Biasing URD: • Biasing • UR 5.1 The user shall be able to apply event biasing and sampling techniques, by specifying particle and • geometry dependent importance (Ref. UR 19-15, and #61): ”The user shall be able to apply event biasing and sampling techniques, by specifying particle and geometry dependent importances” • Need: Essential. • Priority: Implemented. • Stability: Subject to change. • Source: ESA joint project. • Clarity: Clear. • Verifiability: Verified.

6. URD Biasing – PSS-05 format • Currently implemented

7. Neutron Simulation • A number of neutron simulations require event biasing in order to get meaningful results • E.g. Radiation Background, Shielding, Dose calculations • Particularly due to the precise (and CPU intensive) handling of neutron_hp • discrete elastic scattering • Cross-sections calculated at all temperatures

8. URDs – Leading particle biasing • Not always informative!

9. Current Geometrical Biasing • In the default set-up geometrical biasing can be applied to either mass or parallel geometries • Its own parallel navigation is included • Can only be applied to neutral particles (no field or multiple scattering!) • Addresses a number of use case caveats • Strongly coupled to scoring (more later) • 1 Test, 3 extended examples and 1 advanced example are provided • Functionality tested but not performance in terms of physics/variance reduction (CPU gain, statistical significance and variance of output/observable, etc…)

10. Limitations of "parallel" geometries • Current scenario has the following limitations: • The world volume of the parallel geometry must overlap the world volume of the mass geometry (i.e. be larger) – still reports of a bug in this… • Particles crossing a boundary in the parallel geometry where there is vacuum in the mass geometry are also biased. This may be optimized in later versions (not done). • Mass and parallel geometry boundaries should not be coincident in the current implementation (to be verified). • Charged particles and fields not handled • Scoring strongly coupled to biasing geometry – requirement?

11. Use Case I • At a boundary, multiple scattering moves the particle back into the original volume • Currently this is treated wrongly, should be fixed with coupled transportation • One reason why only recommended for neutral particles

12. Use Case II • In mass geometry this is treated correctly • In parallel case particle is not located in volume B • Should be fixed in Coupled Transportation?

13. Use Case III • If boundary is in mass volume then this is treated properly in current navigation • In parallel geometry this creates a problem • ParallelImportanceProcess does not occur. Therefore no biasing is applied and the weight is not changed! • Scoring counts a collision in volume A with the wrong weight. • Should be fixed in Coupled Transportation?

14. Use Case IV • A particle crosses a biasing particle with volume B having a greater importance • Copies of the particle are created • Handled correctly

15. Future developments/Coupled Transportation • The use of fields (electric and magnetic) will be permitted along with the ability to bias charge particles (currently only possible for neutral) • Multiple scattering and field transportation will be handled correctly and coherently across parallel geometries • Event biasing and variance reduction will be re-factored once the scoring and related biasing classes/interfaces are defined

16. Navigation in Parallel Geometries

17. Biasing and Scoring • Currently in Geant4 we have two scoring implementations – one attached to biasing • What happens at a boundary? • If flux is measured at a biased boundary then the splitting and killing has to be handled properly • Who limits the step? Pre-defined hierarchy? • In current implementation biasing limits the step, scoring applied secondarily • For new parallel navigation biasing is applied as an AlongStepDoIt – necessary? • Sensitive Detectors attached to parallel world – is it foreseen/possible? • Inter-dependence – scoring has to come after biasing (e.g. if Splitting or Russian Roulette has occurred)

18. Summary • URDs are not exhaustive and could be extended • Current implementation has known limitations which are addressed with the new parallel navigation scenario • Use cases need to be handled properly • Scoring is currently strongly coupled to biasing, a solution needs to be sought where independence and non-duplication can be exercised – abstract interface? • Code refactoring due • Examples and validation vs. physical quantities are required • Room for discussion…

19. Spare slides

20. Biasing example B01 • Shows the importance samplingin the mass (tracking) geometry • Option to show weight window • 10 MeV neutron shielding by cylindrical thick concrete material • Geometry • 80 cm high concrete cylinder divided into 18 slabs • Importance values assigned to 18 concrete slabs in the DetectorConstruction for simplicity. • The G4Scorer is used for the checking result • Top level class uses the framework provided for scoring. Air Air 1 1 2 4 8 16 32 64 ……….. 2n

21. Example of Standard output Analogue Importance Sampling

22. Weight Window Technique • Energy bounds < 1 GeV • Upper limit factor : CU = 1, Survival factor : CS = 1 • Lower limit weight is proportional to 2-n along to slabs Survival weight bounds

23. Flux multiplied by Kinetic energy of particle (MeV)

24. Example B02 • B02 example for showing • importance sampling in a parallel geometry • a customized scoring making use of the scoring framework. • Mass geometry consists of a 180 cm high simple bulk 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’ • Pairs of G4GeometryCell and importance values are stored in the importance store, G4IStore. • The scoring uses the G4CellSCorer and one customized scorer for the last slab. • 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 “b02.hbook" is created.

25. 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 created.