Particle transport and energy cutoffs

How do I replace multiple scattering by single scattering?

To activate single scattering everywhere, use command MULSOPT with the following values:

WHAT(1): 0.0
WHAT(2): 0.0
WHAT(3): 0.0
WHAT(4): 1.0
WHAT(5): 1.0
WHAT(6): > 1000.0
SDUM:    GLOBAL (GLOBEMF applies only to electrons and positrons, GLOBHAD
         only tho hadrons and muons)

Note that this choice is generally extremely demanding in CPU time, except for particles of very low energy (a few keV), which have a very short history anyway. In such cases, the single scattering option is even recommended.

Can light nuclei (like for instance 3-He) migrate from region to region and be stored (by RESNUCLEi card) not in the region where they were born?

Yes, if you have activated recoil transport with EVENTYPE. In general, however, they don't travel very far.

In FLUKA, is energy conserved at the level of each single interaction?

Yes, with the exception of low-energy neutron interactions. In those interactions, energy is deposited by charged recoils. Some of them (protons from scattering on hydrogen and from 14-N(n,p), alphas from 10-B(n,alpha), light fragments from 6-Li(n,x)) are explicitly transported by FLUKA and their energy is deposited by dE/dx. But in most cases, the recoil energy is deposited via kerma factors averaged over all possible reactions for a given energy group, so that energy is conserved on average but not necessarily in a single interaction.

Note that "kerma" in principle refers only to charged particles and not to gammas. But in the unlucky case of Germanium, and of some other elements listed in Chap. 10 of the manual, gamma production is not available. In such cases, the energy of the gamma(s) is added to the kerma, making the situation even worse.

The reason for this is that the NJOY code, which is used to process the evaluated data files (ENDF, JEF, JENDL...), calculates kerma as the result of an energy-mass balance: and whatever energy cannot be accounted for is added to the kerma. This is clearly a weakness of the system, intrinsically related to the way the neutron cross section databases are built (in some cases one even gets negative values due to inconsistencies in the evaluated neutron cross section databases).

No separate balance for each transition can be done due to the lack of correlations in the original databases: only averaging over all transitions make sense and produces exact, albeit uncorrelated, dose calculations (within the limit of the evaluated databases accuracy).

How are K0 and anti-K0 related to K_short?

The question of K0's in FLUKA is very complicated. You can have "pure states" and superpositions of states, hadronic and leptonic, short and long: and some of these are relevant at production time but not at transport time and vice-versa.

FLUKA considers in different ways neutral Kaons according to their origin: If kaons0 are coming from the weak decay of some resonance, like for instance a phi particle, where the transport eigenstates matter, then they are labelled KAONLONG (I.D.: 12) and KAONSHRT (I.D.: 19). Otherwise, if they are coming directly from the hadronisation chain, or from strong decays of resonances, they are labelled KAONZERO (I.D.: 24) and AKAONZER (I.D.: 25), according to their parton content. These kaons, during particle transport, are then treated as a proper combination of KAONLONG and KAONSHRT in order to have the right decay properties.

From the point of view of hadronic interactions instead, only KAONZERO and AKAONZER have meaning. Therefore, if a KAONLONG has to interact with another hadron it is first decomposed in KAONZERO/AKAONZER.

I would like to score stars in an Al shell from a carbon source. The total number and weight of stars get zero.

The transport of ions is off by default and has to be invoked by the user with WHAT(3) of the EVENTYPE card. Note that this switches on only ion *transport*. In order to simulate ion *interactions* the event-generators DPMJET and RQMD have to be linked using the script ldpm3qmd which is located in the flutil subdirectory. Also keep in mind that no nuclear interactions are simulated below 100MeV/n in the present version.

I do not see the phi(1020) meson appearing in the list of transportable Fluka particles. Does it mean that this particle (resonance) is discarded completely?

No: FLUKA distinguishes between particles that are produced (COMMON block PART) and particles that are transported (COMMON block PAPROP). All particles and resonances listed in Particle Data Group, with the exception of those containing quarks heavier than charm, are produced. Those which have a very short lifetime, i.e. the resonances with hadronic decay, are decayed immediately after their production. The reason is that even at the highest energies their path would be irrelevantly short. In particular phi(1020) is indeed produced and has its decay list according to measured branching ratios, in this case K+K- (49.2%) and Klong Kshort (34%).

Internally to the code, produced particles and transported particles have different numbering schemes. Only transported particle numbers are normally accessible to the user.

I am interested in the bremsstrahlung generated by an electron beam. However would like to kill any electrons or positrons with energies below the beam energy as, in reality, they are removed by a magnet. How can this be done?

Define a thin region with a material of low density in which you set the transport thresholds for electrons and positrons to a value just below beam energy (card EMFCUT). Electrons and positrons would then be stopped in that region with the energy entirely deposited at the stopping point. The region should be thin enough (and of low-density material) such that other particles interact as little as possible in it. Note, that the region cannot be vacuum. Electron transport cutoffs are not allowed in vacuum since the energy deposition (at the stopping point) would be unphysical.