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

Informativa cookies