I unintentionally transported RAY particles through the ALICE set-up (by assigning id = 0 for b-hadrons unknown to FLUKA) and got a “STOP IETAB > MXTBGE” abort. After some debugging I found out that the abort is caused by 5 MeV photons that enter a material which has photon transport cut > 5 MeV. The 5 MeV photon energy is the Compton threshold set in: cascade/kasray.f: EKING = 0.005D+00. If one comments out the abort the energy is increased in steps of 25% until it passes the cut.
This might be a bug or a feature (no transport cuts for RAYs allowed ?). However, the output could be more informative, e.g. “IETAB < 0 at 5 MeV Compton threshold, check your photon transport cuts in material XXX.”
Thank you very much for reporting the FLUKA abort that you witnessed.
Going straight to the point: are you using your own user routine? If so, do you have a BEAM card in the input file with an energy/momentum (even its default value!) well below the maximum value that your custom source might set?
Assuming that the answer to both questions is affirmative, the abort message you witness is actually unrelated to photon transport thresholds. When tracking RAY particles FLUKA of course does not produce photons, but it will require photon cross sections for output purposes. The latter are tabulated at initialization essentially up to the energy prescribed by the BEAM card (with some safety margin). If photon cross sections are requested at an energy exceeding what the BEAM card prescribed (e.g. because the source routine puts a much higher energy) the tabulation search fails (the index goes way beyond what is expected) and the code wisely aborts. Raising the momentum/energy in the BEAM card accordingly should solve the problem.
If the answer to either of the above questions is negative, let us know the most convenient way to reproduce the abort (that we have obtained for the aforementioned circumstances, region/material threshold independent).
Staying attentively tuned,