Order of Events: mgdraw.f Output

Dear FLUKA experts,

I’m running a simple simulation of a high energy neutron beam and am trying to convert mgdraw output into a tree of sorts where each event is a node that points to its parent and to its children which are also events. However, my exogenous code doesn’t seem to work properly. The mgdraw output is dictated by the usrdraw routine:

      ! Write out the event attributes, type, parent, position, region
      ! Write out how many product particles were produced and their respective codes
      WRITE(72,*) NP, (KPART(I),I=1,NP)
      ! Write out fragments produce (pieces of nuclei) A followed by Z
      ! Write out the Residual A and Z (if there is one)
      WRITE(72,*) ICRES, IBRES
      ! Write out the parent attributes
      WRITE(72,*) (ISPUSR(I),I=1,4), (SPAUSR(I),I=1,7)


            ! Integer values
            ISPUSR(1) = ICODE
            ISPUSR(2) = JTRACK
            ISPUSR(3) = MREG
            ISPUSR(4) = LTRACK
            ! Float values
            SPAUSR(1) = ETRACK
            SPAUSR(2) = XSCO
            SPAUSR(3) = YSCO
            SPAUSR(4) = ZSCO
            SPAUSR(5) = CXTRCK
            SPAUSR(6) = CYTRCK
            SPAUSR(7) = CZTRCK


and my pseudocode for turning the output file into a tree is something like the following:

  1. Load in entries from the list linearly— these are events characterized by 5 lines of data. Separate the data into their appropriate variable names.
  2. Go linearly through the new list of “pseudo-events” (python dictionaries). If the event has a parent (ISPUSR(4) = parent LTRACK is not 0), find its parent in the events already loaded in***. Add the current event as a child to the found parent.
  3. Repeat step 2 for all subsequent events.

Now for the base case, the first event, I set the parent to None and continue.

*** This may be my flawed assumption— do the events print to the output file in parent-child order?

Otherwise, please respond with any advice. It would be greatly appreciated.

Thank you,


Hello @rross ,

Looping over the tree of events in FLUKA is indeed done in a sequential manner. Let’s say your primary neutron A has an inelastic interaction producing secondaries B and C which are explicitly transported. If in turn secondary B produces tertiary particles D and E, these are tracked first and sequence, then the code goes again one level up in the tree to particle C and tracking all it’s possible subsequent interactions and daughter particles, and so on… .

It is not entirely clear to me where your problem exactly is situated or how the code gives problems. Perhaps you can try in incremental steps, simulating only one primary interaction but already stopping the (pseudo-) code before producing more secondaries and checking if they are written out in the order you expect. You can make sure to each time use the same random number seed to do these tests by correctly setting the RANDOMIZ card.

Allow me to also point you to a couple of other threads which could give some inspiration for your work (in case you didn’t check these yet), on getting isotope information, on extracting parent particle information and on accessing secondary particle information.

Hope this is helpful, cheers,


Hello Andreas,

Thank you, this was indeed helpful. I’m left however with (at least) two questions:

  1. Could there be particles in the output which have produced secondaries that do not appear as elements in the output? As in, FLUKA does not track these secondaries at all.
  2. Does every particle produced in the tree have an “end” event?

I ask this because while I’ve found every event/particle has a unique parent, some have a list of secondaries (JTRACK variables), say, [ J0, J1, …, JN ] that do not all correspond to an event in the output file.

Thank you very much for your response!


Hi @rross ,

It is possible that particles are not explicitly tracked since the energy at which they are produced fall below the transport threshold in the simulation. In this sense also the “end” of an event corresponds to a particle falling below transport threshold. For this you should carefully check your simulation settings (DEFAULTS, PART-THRes, EMFCUT, … etc. cards), perhaps you can check what happens to the list of outputs when you vary the thresholds, i.e. setting them to lower or higher values.



Thank you, Andreas. This is exactly what I needed to know.