Improvements of sampling and scoring
( User Requirements: Scoring for event biasing options)
Tsukasa Aso,
Toyama National College of Maritime Technology, Japan
Contents
► Objective
► Current
scoring options
► Migration from geometry biasing scorer
► User requirements
► Summary
Objective
►
The main goal of improvements of scoring is to provide a
user with common sampling scheme under:
 event biasing
► Geometrical
biasing
► Physics process biasing
 All the influences of these biasing will be reflected to the “particle weight”
in order to keep a consistency of the result
 parallel geometry
► ParallelWorldScoringProcess
has already been available
► Geometrical biasing is migrated to using parallel geometry. (by Alex)
 The geometry must be identified by the geometry number,
i.e. copy number or replication number
►
Scorers must be applicable by same manner
 in both of mass and parallel geometry
 with or without event biasing
Current scoring options
► There
are three kinds of scorers
 Sensitive Detector
► Users
have to implement own detector class and hit class
 MultiFunctional Detector with Primitive Scorer
► Geant4
provides many scorers
► Users can compose own scorer by combining those scorers
► Keys of maps are redundant for scorers of same volume
► More improvements are desirable for efficient scoring
 Event biasing scorer
► Useful
► By
quantities for checking geometrical biasing
► Sampling at Entering/InVolume/Exiting is useful for users
► Must work with geometrical event biasing
► Event biasing process becomes more simple if the scorer is
separated from geometrical biasing
separating the role, we can make it simple
 Process, Process Placer, Scorer
Migration from event biasing scorer
► Geant4
provides examples at
example/extended/biasing/B01~B03
 B01 Mass geometry
 B02 Parallel geometry, AIDA
 B03 using Python
► Test
version of parallel geometry ( by Alex )
 B01_para Mass geometry
 B02_para Parallel geometry
►
Detail in event biasing scorer
 default scoring quantities
►
►
►
►
►
►
►
►
►
►
►
Entering track G4PSTrackCounter
Population
G4PSPopulation
Collision
G4PSCollision
SL
G4PSTrackLength
SLW
G4PSTrackLength
SLWE
G4PSTrackLength
SLWE_v
G4PSTrackLength
SLW_v
G4PSTrackLength
NumWGTedE = SLWE_v/SLW_v
(Run)
FluxWGTedE = SLWE/SLW
(Run)
Av.Tr.WGT = SLW/SL
(Run)
1
1
x
 Problem in event biasing scorer
Since the biasing has to access to the both of volume in geometrical boundary,
Scoring in given function basically stores quantities for “poststep” volume.
► It should be unified to the volume of “prestep”
►
 ScoreAnExitingStep(aStep,pre_gCell)
 ScoreAnEnteringStep(aStep,post_gCell)
 ScoreAnInVolume(aStep, post_gCell)
►
To use the volume in “poststep” causes miss the sampling step information.
 At the geometry boundary
 At the world volume boundary
=>This is mentioned in User’s manual. “Scoring cells must not share boundaries with
the world volume.”
B01
Mass geometry
Importance / Scoring
WorldVolume
(shieldWorld)
18 slabs
(cell_01 ~ cell_18)
R=100cm
10 MeV neutron
+-100cm
1 slab for score
(rest_rep)
►
For comparison, PS are created for reproducing the event
biasing scorer. ( B01 )
i.e. use “prestep/poststep” volume in some case.
Completely same result
Copy number of volumes are assigned for primitive scorer
Regular scoring using prestep volume (B01_para)
►
Difference comes from
 boundary identification of volumes
 steps to the out of world volume.
InVolume quantities are same.
Boundary related quantities are different
B02_para
R=101cm
Mass
R=100cm
Ｚ=+- 90cm
Para
10cm thick slab
In parallel geometry
►
Importance/PS are attached to same parallel geometry
Here I changed G4ParallelWorldScoringProcess:CopyStep(const G4Step) for setting
geometry boundary of PreStepPoint.
Executed without serious problem
Importance
Mass
Scoring
Mass
△
Parallel1
△
Parallel2
Parallel
But result are different each other
by the choice of transportation,
Transportation
CoupledTransportation
Executed but the result is not same
as Mass-Mass combination.
○
○
Exactly same result.
But if the biasing scorer is turned off,
the result of PS is changed.
=> This difference come from interaction???
See next slides.
Parallel
10
9
8
7
FluxWGTedE
6
w/o bs
w/ bs
5
4
3
2
1
0
1
2
3
4
5
6
7
8
9
10
11
Cell ID+1
12
13
14
15
16
17
18
19
20
When turning off the biasing scorer, the result is changed by physics interaction?
Question from biasing example
 Every process for parallel world geometry
checking and identifying the geometry boundary
in parallel world
 Is there any possibility to merge it?
i.e. a process for giving step status for the
parallel world.
User requirements(1) ~Other MC~
Elemental quantities
Current
Flux
Fluence
Physics quantities
MCNP4B
Surface current
Surface Flux
Cell Flux
Point Flux
Geometrical condition
After MCNP4B
Mesh Tally
- Rectangular
- Cylindrical
- Spherical
FM
(read/store)
After MCNP4B
Mesh Tally
- Track averaged
(tracks, flux, dose)
- Source
(coincidence, anticoincidence)
- Energy deposition
(total, de/dx,…)
- DXTRAN
- Image projection
- Point detector
FLUKA
USRBDX
USRYEILD
(surface)
SCORE
USRBIN
(space)
USRTRACK
(energy deposition of the volume)
EVENTDAT
EVENTBIN
DETECT
USRCOLL
RESNUCLEi
Time window
Coincidence capture
…
User requirements(2)~scorer~
► The
primitive scorer has been already provided
interest physics quantities.
(This is because we started from MCNP tally for
primitive scorer development)
► Current options does not involve any support to
define scoring geometry
Tally = Geometry + Sampling + Scoring
► Scorer needs to get differential distributions
Energy distribution, Angular distribution,
or double-differential distribution
User Requirements(3)
UR.1
Geometry boundary can be identified by
the value of StepStatus
User can easily
distinguish the step
condition
EnteringStep,
InVolumeStep,ExititingStep
may be also helpful.
UR.2
The volume can be identified by the
volume name and its copy number
User need to identify
what volume should be
assigned for scoring
A kind of volume ID is
useful. This is important in
mass geometry.
UR.3
The scorer must be extensible for
implementing user hook actions
For example, user want
to use AIDA inside
scorer
The concept is almost same
as PrimitiveScorer
UR.4
Scoring space, i.e. mesh, should be defined
by UI command or helper class.
(Rectangle, Cylindrical, Spherical)
User defined scoring
geometry
Probably in parallel
geometry.
UR.5
Surface should be defined by UI command
or helper class
(Rectangle, Cylindrical, Spherical)
User defined scoring
geometry
Probably in parallel
geometry. More
sophisticated definition of
surface is necessary.
UR.6
Scorers are composed and attached to the
scoring geometry
more than one physical
quantities can be scored
in one scoring volume.
The concept is same as
MultiFunctionalDetector
UR.7
A scorer may have differential distributions,
so that the binning can be specified by the
user.
i.e. energy distributions,
energy-binned flux etc.
Current hits collection of
primitive scorer has to be
modified
UR.8
Data size for scored result and execution
time should be as small as possible
Key of geometry index
should be used
commonly
Current hits collection of
primitive scorer has to be
modified
User Requirements(4)
UR.9
Scoring results may be accessed at the end
of event or be accumulated during the RUN
i.e. energy deposit of
calorimeter per a primary
particle, or flux of entire run.
UR.10
A scorer can have a filter for track selection.
i.e. particles, energy window
UR.11
Source coincidence
?? Particle Gun Number
?? Produced position
UR.12
Timing window
??
UR.13
Triggering
??
UR.14
UR.15
UR.16
Summary
► Migration
from event biasing scorer to
primitive scorer will be possible
 Still we have to investigate the differences
► The
new scoring capabilities will be
designed and implemented
► The some of example using new scorer,
event biasing, and parallel geometry will be
presented