Collision tape¶
What is a collision tape and what is its purpose¶
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 MGDRAW: general event interface)
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 into 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 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 Note 4), 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 MGDRAW: general event interface).
How to write a collision tape¶
To obtain a collision tape, option USERDUMP must be input with WHAT(1)≥ 100.0.
The user can choose to dump all data concerning
particle trajectories,
data concerning continuous energy deposition
data concerning local (point) energy deposition
any combination of the three above
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 MGDRAW: general event interface).
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 2 |
(First variable |
< 0): |
source particles |
NTRACK, MTRACK, JTRACK, ETRACK, WTRACK(three integers and two real variables)
(XTRACK(I), YTRACK(I), ZTRACK(I), I = 0, NTRACK),(DTRACK(J), J = 1, MTRACK), CTRACK(that is,NTRACK + MTRACK + 1real variables)
where:
|
= |
number of trajectory segments |
|
|
= |
number of energy deposition events along the trajectory |
|
|
= |
particle type (see Particles transported by FLUKA) |
|
|
= |
total energy of the particle (rest \(+\) kinetic) |
|
|
= |
particle weight |
|
|
|||
for |
|||
|
= |
energy deposition in the |
|
|
= |
total curved path |
0, ICODE, JTRACK, ETRACK, WTRACK(three integers and two real variables)
XSCO, YSCO, ZSCO, RULL(4 real variables)
where:
|
|
|
|
|
|
|
|
= |
= |
|
= |
|
= |
|
= |
|
|
= |
= |
|
= |
|
= |
|
= |
|
|
= |
= |
|
= |
|
= |
|
|
= |
= |
|
|
= |
= |
|
= |
-NCASE, NPFLKA, NSTMAX, TKESUM, WEIPRI,(three integers and two real variables)
(ILOFLK(I), ETOT(I), WTFLK(I), XFLK(I), YFLK(I), ZFLK(I), TXFLK(I), TYFLK(I), TZFLK(I), I = 1, NPFLKA)(NPFLKAtimes (that is, one integer \(+\) 8 real variables))
where:
|
= number of primaries treated so far (including the current one) |
|
|
= number of particles in the stack |
|
|
= maximum number of particles in stack so far |
|
|
= total kinetic energy of the primaries of a user written |
|
|
= total weight of the primaries handled so far |
|
|
||
|
= total energy of |
|
|
||
|