Last version:
, October 16th 2024 (last respin 2024.1.2) 06-May-2024
|
[ <--- prev -- ] [ HOME ] [ -- next ---> ] [ full index ]
11 Collision tape
A "collision tape" is a file where quantities describing selected events
are recorded in the course of a FLUKA run.
This file is the standard output of the MGDRAW user routine, that can be
customised by the user to get different and/or more complete output
(see description of user routine MGDRAW in Chap. (13)).
Note that "event" would be a more appropriate word than "collision",
and "file" better than "tape". For historical reasons, however,
the expression "collision tape" is used in Monte Carlo jargon rather
than "event file". It is true that most interesting events are generally
collision events (but also boundary crossings, decays, etc.), and that
the large size of the file may require the use of a magnetic tape (or at
least, that was often the case in the past).
Recently, the expression "phase space file" has also been used.
There are several reasons for which the user might decide to write a
collision tape. Some examples are:
-
to perform a non-standard analysis or scoring. In general, this is
not recommended because the available FLUKA scoring facilities are
reliable, efficient and well tested. However, there may be special cases
where a user-written scoring is necessary.
-
to save details of transport for a new independent analysis. In this
case, however, the user must make sure that no phase-space region
of interest be undersampled because of biasing options in the
corresponding run. As a general rule, writing of a collision file is not
recommended in non-analogue (biased) calculations.
-
to connect FLUKA to other radiation transport codes (now less
likely than in the past, since FLUKA covers most energy ranges
and transports most particles which can be of interest).
-
to split the transport problem in two or more sequential phases.
A technique used in deep penetration calculations, which can be
considered as an extension of splitting, consists in recording
all particles crossing a given boundary (with their energy,
weight, coordinates and direction cosines at the point of crossing),
and to sample repeatedly source particles from that set in a
successive run (Fas87). A special subroutine SOURCE (see (13) and
option SOURCE) must be written for this purpose. The user must make
sure that the final normalisation is done with respect to the total
particle weight used in the first step of the procedure, and not
to that of the second step. It is also recommended to assign blackhole to
all materials immediately beyond the recording boundary, to avoid that
backscattered particles be considered twice.
-
to perform some manipulation in an intermediate phase of Monte
Carlo transport. An example is a variation of d), in which a user
program interpolates some smooth analytical distribution through
the recorded quantities, from which source particles are sampled
in the next FLUKA run.
-
to trace suspected errors in transport
-
to connect to a graphical display program
FLUKA allows to write a complete dump of each source particle, of each
trajectory and of each energy deposition event, possibly under event-driven
conditions specified by the user (see description of user routine MGDRAW
in (13)).
11.1 How to write a collision tape
To obtain a collision tape, the user must input option USERDUMP with
WHAT(1) >= 100.
The user can choose to dump all data concerning particle trajectories, data
concerning continuous energy deposition, data concerning local (point) energy
deposition, or any combination of the three. By default, data are written on
the collision tape in single precision and unformatted, but it is also possible
for the user to modify the MGDRAW subroutine and to obtain a more customised
output file (see (13)).
The variables written by the default version of MGDRAW}, and their number,
differ in the three cases. The sign of the first (integer) variable dumped at an
event indicates how to interpret the following ones:
-
Case 1 (First variable > 0 ): continuous energy deposition
-
Case 2 (First variable = 0 ): point energy deposition
-
Case 3 (First variable < 0 ): source particles
In Case 1, the following variables are written:
First record:
NTRACK, MTRACK, JTRACK, ETRACK, WTRACK,
(three integers and two real variables)
Next record:
(XTRACK(I), YTRACK(I), ZTRACK(I), I = 0, NTRACK),
(DTRACK(J), J = 1, MTRACK), CTRACK
(NTRACK+MTRACK+1 real variables)
where:
NTRACK = number of trajectory segments
MTRACK = number of energy deposition events along the trajectory
JTRACK = particle type (see (5))
ETRACK = total energy of the particle (rest + kinetic)
WTRACK = particle weight
XTRACK(I), YTRACK(I), ZTRACK(I) = coordinates defining the upstream
end of the (I+1)th segment; for I = NTRACK, the end of the
trajectory
DTRACK(J) = energy deposition in the Jth deposition event along the
trajectory
CTRACK = total curved path
In Case 2, the following variables are written:
First record:
0, ICODE, JTRACK, ETRACK, WTRACK
(three integers and two real variables)
Next record:
XSCO, YSCO, ZSCO, RULL
(4 real variables)
where:
JTRACK, ETRACK, WTRACK have the meaning explained above,
XSCO, YSCO, ZSCO = coordinates of the energy deposition point
RULL = amount of energy deposited
ICODE = indicates the type of point event giving raise to energy
deposition, as explained below:
1x = call from KASKAD (hadronic part of FLUKA);
10: elastic interaction recoil
11: inelastic interaction recoil
12: stopping particle
13: pseudo-neutron deposition
14: escape
2x = call from EMFSCO (electromagnetic part of FLUKA);
20: local energy deposition (i.e. photoelectric)
21: below user-defined cutoff
22: below user cutoff
23: escape
3x = call from KASNEU (low-energy neutron part of FLUKA)
30: target recoil
31: neutron below threshold
32: escape
4x = call from KASHEA (heavy ion part of FLUKA)
40: escape
5x = call from KASOPH (optical photon part of FLUKA)
50: optical photon absorption
51: escape
In Case 3, the following variables are written:
First record:
-NCASE, NPFLKA, NSTMAX, TKESUM, WEIPRI,
(three integers and two real variables)
Next record:
(ILOFLK(I), ETOT(I), WTFLK(I), XFLK(I), YFLK(I), ZFLK(I), TXFLK(I), TYFLK(I),
TZFLK(I), I = 1, NPFLKA )
(NPFLKA times (one integer + 8 real variables))
where:
NCASE = number of primaries treated so far (including current one)
NPFLKA = number of particles in the stack
NSTMAX = maximum number of particles in stack so far
TKESUM = total kinetic energy of the primaries of a user written
SOURCE
WEIPRI = total weight of the primaries handled so far
ILOFLK(I) = type of the Ith stack particle (see (5))
ETOT(I) = total energy of Ith stack particle
XFLK(I), YFLK(I), ZFLK(I) = source coordinates for the Ith stack particle
TXFLK(I), TYFLK(I), TZFLK(I) = direction cosines of the Ith stack particle
|