[fluka-discuss]: Major new FLUKA release fluka2020 is out

From: Paola Sala <paola.sala_at_mi.infn.it>
Date: Fri, 17 Jan 2020 10:55:34 +0100

Dear Fluka Users,

I have the pleasure to announce a new major FLUKA release.

fluka2020.0beta is now available on the www.fluka.org website

This brand new release includes plenty of improvements and new
features, which, while they have been extensively tested and debugged,
could still be subject to residual hidden problems, hence the "beta"
appellation. Therefore, for a few weeks both fluka2011.2x.8 and
fluka2020.0beta will available on the web site, and assistance will be
provided for both. Please SPECIFY WHICH VERSION you are using,
possibly in the subject, when asking for help at

The changes with respect to fluka2011.2x.8 are reported in the
release notes included below (also on the website and within the fluka

Copyright and licensing conditions have changed too, the website will
automatically ask you to accept them before downloading. Users who
already asked access to the source code will simply have to reconfirm
acceptance of the license: they will receive a message with details.

A corresponding Flair version will be released soon.

The Fluka team

- Release notes for Fluka2020.0beta -

This is a major release with several important physics and technical
improvements and additions.

This fully brand new release includes a plethora of improvements and new
features, which, while they have been extensively tested and debugged,
could still be subject to some residual hidden problem, hence the "beta"
appellation. For this reason, for a few weeks both fluka2011.2x.8 and
fluka2020.0beta will available on the web site, and assistance will
be exceptionally provided for both. Please SPECIFY WHICH VERSION you
are using, possibly in the subject, when asking for help at

Please take note of the revised license, which you can find in the
LICENSE.2020.0beta file, or printed by the code when it runs.

The most relevant new features are described below, those flagged "(#)"
are either particularly complex, or brand new, and therefore more
prone to possible residual rare issues


- The PEANUT model has been significantly improved in the energy range
  from a few GeV's on. Comparisons with experimental data for
  production in the 10-20 GeV range shows noticeable improvements
  in the predicted distributions, particularly for heavy targets. The
  introduction of cross section fluctuations now allows better
  predictions of multiplicity distributions of fast hadrons in the
  multi-GeV regime, with impact on computed calorimeter resolutions (#)

- Electro-nuclear reactions are now implemented and can be activated with
  the PHOTONUC card with sdum=ELECTNUC (see the manual for further details)

- Muon-nuclear reactions are now extended down to virtual photon energies
  in the quasi-deuteron and Giant Dipole Resonance regions with significant
  improvements in the predictions of cosmogenics backgrounds

- Electro-Magnetic-Dissociation has been inproved introducing also
  the Electric Quadrupole (E2) contribution, of particular importance
  at the lowest energies

- An extended and improved nuclear database allows better treatment
  of unstable nuclei near the neutron and proton drip lines.
  Masses, decay channels and branching ratios have been extensively
  revised. Many more isomers are now included in the database:
  conventionally FLUKA considers "isomers" all excited states with
  half-lives in excess of 1 microsecond. Please note that residual
  nuclei output files from previous versions cannot be processed
  with the fluka2020.0 auxiliary routines, because of their dependence
  on the nuclear database.(see below)

- The inclusion of many more isomers makes the old, crude, 50-50%
  estimate for isomer vs ground state production rather questionable.
  That estimate, applied a posteriori and only for activation and
  residual dose rate purposes, becomes more and more unphysical,
  particularly for nuclei with more than one isomer (eg a nucleus with
  3 isomers would be scored on a 25-25-25-25% basis). An attempt
  to evaluate isomer production "a priori" during the nuclear model
  evolution is now implemented. It is still rudimentary, but it should
  be already better than the old ansatz. Together with the isomer
  production data now available in the neutron cross section file
  (see below), it should significantly improve isomer production
  predictions. It should be noted that now isomers, when produced,
  are allowed to fly until stopping, since their half-life is such
  that they will hardly decay before stopping in most practical
  problems. The new isomer production mechanism can be switched
  off (strongly discouraged) by setting What(1)=-1 in a PHYSICS
  card with sdum=ISOMERS (#)

- A deuteron pre-formation production mechanism by light nuclei has been
  implemented, resulting in much better predictions of excitation
  functions of reactions like (p,d)/(p,pn), (n,d)/(n,np) on light nuclei
  at low and intermediate energies. This mechanism is automatically
  activated if the user requests COALESCEnce (PHYSICS card) as

- Direct reactions to IAS (Isobar Analogue State) have ben implemented
  for a few isotopes of particular importance as neutron producing
  targets, resulting in major improvements in the prediction of
  neutron spectra at forward angles at low to medium energy (#)

- Full account for discrete levels, out of the (IAEA) Ripl-3 library,
  is now implemented in every nuclear reaction step/generator

- Heavy fragment evaporation up to Z_max=4, A_max=9, is now automa-
  tically activated when the PRECISIOn default is selected. For
  residual nuclei activation and/or dose rates it is recommended
  to activate heavy fragment evaporation up to the maximum Z and A
  implemented (eg with what(1)=3.0 in the PHYSICS card with sdum

- A simplified model for angular momentum barriers is now implemented
  inside the Fermi break-up de-excitation model whenever emission
  cannot occur with L=0. Major improvements in residual nuclei
  predictions for virtual or real photons on light nuclei in the
  GDR region had been observed thanks to this extension

- Photofission is back working in reasonable shape

- The high energy fission model has been improved. Further work on
  this topic is scheduled in the near future

- Fission fragment yields by low energy neutrons (neutrons below 20 MeV)
  are now based on the most recent evaluations, Endf/b-VIIIr0,
  Jeff-3.3, and Jendl-4.0

- Neutron cross sections for several isotopes had been updated with
  more recent evaluations, mostly Endf/b-VIIIr0. The Tellurium cross
  sections have been added (see the manual for further details).
  As a consequence of the availability in Endf/b-VIIIr0 of some isotopes
  previously missing (eg 13C, 17O, 18O) the FLUKA identifier for some
  elements are now different (eg for OXYGEN), please refer to the
  manual for further details

- Neutron cross sections now contain the information for production of
  isomers, out of the European Activation File. Therefore isomer
  versus ground state production by low energy neutrons is no longer
  based on the "old", crude, estimate 50-50%, but it is rather calculated
  according to the evaluated values when available (#)

- Fully correlated pointwise cross sections are now available for
  neutrons below 20 MeV for 2-H, 3-He, 4-He and 12-C (in addition
  to 1-H and 6-Li which were already implemented). They are
  automatically selected when What(6) of LOW-NEUT is set to a suitable
  value (see the manual), or by default for some DEFAULTS, if the
  material name is respectively DEUTERIUM, HELIUM-3, HELIUM-4,
  CARBON/C-12/12-C/C-NAT/NAT-C (all 5 are recognized for Carbon)

- (Anti)Neutrino cross sections have been revised and improved,
  particularly at the higher energies, and for charm production

- A preequilibrium step, based on the PEANUT one, has been introduced in
  the rQMD event generator. Together with other improvements this results
  in significantly better reproduction of ion-ion experimental data,
  particularly towards the bottom energy range of application of rQMD

- A preequilibrium step, based on the PEANUT one, has been introduced in
  the BME event generator when the projectile-target/pre-fragment
  combination is not one of those pre-calculated in the BME database.
  This addition results in significant improvements particularly for
  (very) light projectiles on heavy targets. There are still some
  weaknesses for intermediate-to-heavy projectiles on
  intermediate-to-heavy targets, with BME somewhat overpredicting
  ejectile high energy tails

- Alpha-Nucleus cross sections for light nuclei have been updated
  according to the recent expreimental data, bringing better agreement
  with measured attenuation curves and Bragg peaks

- A special treatment has been implemented for some exo-energetic,
  low energy reaction cross sections, in particular p-11B, Alpha-18O,
  Alpha-17O, Alpha-13C

- Default damage threshold energies when asking DPA estimates are now
  available for all elements. The user can still override them by
  inputting her/his own values. Please note that widely different values
  are sometimes available in the literature for the same element, hence
  care must be used when using these default values. Also they apply
  to elements, for compounds/mixtures no specific default is available

- Explicit emission of Alpha particles is now included in the radioactive
  decay part, for isotopes whose alpha decay energies and branchings
  are known.


- Dynamic memory allocation for the blank common is now supported
  in the Gfortran versions. The code allocates a preset memory size
  and automatically increases it whenever a USRBIN/EVENTBIN or VOXEL
  card so requires. If the available memory is exhausted somewhere
  else (i.e. geometry), or anyway is she/he so wishes, the user can
  ask for a larger preset (blank common) memory by selecting
  a proper value with What(6) in the GLOBAL card. Max ~4GB.

- The maximum region number is now set at 100000 for the G77 version,
  while it is "unlimited" for the Gfortran version thanks to the
  dynamic memory allocation. For both versions all region number
  dependent arrays are now allocated in blank common according to
  the actual number of regions, with the exception of one, dynamically
  allocated by Gfortran and statically set to 100000 for G77 (#)

  treatment planning system like multi-energy/position beams to
  be used (see the manual for further details)

- The special SPECSOURce sdum BIN-SOUR can be used to create a spatially
  distributed source out of a USRBIN file (eg a radioactive isotope
  distribution, see the manual for further details)

- The Earth magnetic field according to the latest (December 2019)
  release of the International Geomagnetic Reference Field (Igrf13)
  has been implemented into the code and it is an option for space
  and cosmic ray calculations

- The PYX, PYY, PYZ (PYramid along X, Y, or Z axis) bodies have been
  added to the geometry (#)

- Up to two nested roto-translations are now allowed in geometry, both
  for bodies and lattices (see the manual, in particular the new
  option LATTSNGL, for details)

- Parentheses in region definitions are now evaluated run time, if the
  initialization time expansion results in too many terms

- The rQMD event initialization has been made significantly faster,
  resulting in speed-up factors up to x3 for light projectiles

- Hadron masses and physical constants have been updated to the values
  reported in the PDG 2018 edition


We would like to stress once more that whenever activation is a concern or,
"precise" particle production calculations are required, the PEANUT extended
model, as well as heavy particle evaporation/fragmentation and coalescence
should be switched on (see below for details)

- Already starting from Fluka2006.3, a new high energy event generator had
  been developed, based on the sophisticated nuclear physics of PEANUT
  coupled with the proved FLUKA Dual Parton Model description for
  hadron-hadron collisions and a brand new Glauber cascade treatment.
  from fluka2011.2x release, this model is substituting as default the old
  (PEANUT was already the default below 5 GeV).
  All thin target benchmarks of the code by the development team are run
  with the new model, the development of the old one being frozen. Only
  this model should be considered representative of the ultimate FLUKA
  performances. The PHYSICS card with SDUM PEATHRESH allows to switch back
  to the old model (highly discouraged)
  Also the new model potentially provides a fully featured simulation of
  high energy quasi-elastic events, but this requires cleaning up some FLUKA
  inconsistencies and therefore is not yet activated.

- Whenever residual nuclei (and residual dose rates) scoring is of
  importance, or accurate neutron yields are required, the heavy residual
  emission ("fragmentation") and the coalescence emission of fast complex
  particles should be switched on, through the following data cards:


  and (as a consequence of coalescence) it would be wise to link with
  rQMD-2.4 (and DPMJET) and activate ion transport and interactions. These
  suggestions are mandatory for residual nuclei calculations.

  Those options are not on by default because the heavy evaporation carries a
  big CPU penalty which would be a waste for most problems when residuals are
  not a issue. Starting from Fluka2020.0, heavy evaporation is on by
  default (limited to A_max=9, Z_max=4) when the PRECISIOn default is

- The ARB, BOX, WED body types, which are deprecated since many years due to
  their precision problem prone coding, are now accepted only if the user
  explicitly sets SDUM=DEPRBODY in the GLOBAL card. They will disappear
  with the next full release. The same geometrical shapes can be obtained in
  a safer way using a combination of the other body types and of

- !!!! MAJOR WARNING, please read !!!!
  The use of so-called "expressions" inside the Flair preprocessor, those
  writing pseudo-comments in the input file like
  has been found to be prone to potentially dangerous situations, where
  FLUKA runs with parameters different from those intended by the user with
  no detectable warning. This is particularly true if a Flair generated
  input is modified by editing it outside Flair or viceversa, or in all
  cases where inputs using the #include directive together with those kind
  of expressions or similar operators are modified in Flair.
  The developer team has identified already a few scenarios where because of
these shortcomings of the Flair implementation, FLUKA could run with a
  setup different from the one shown in the Flair screen.
  Therefore it is STRONGLY recommended to refrain from using such Flair
  features until a safer implementation will be available (the developer
  team is working on it). If you cannot avoid using those features, please
  ALWAYS CHECK what ended up into the input file (and the corresponding
  interpretation in the output file), since what will be actually
  run is what is written in the WHATs fields of the
  input file (!... comments ignored) and not what the Flair screen can
  show in case they are different. Warnings have been added in the .err
  and .out files for this purpose.
  In order to still use those kind of expressions, the user has to
  explicitly set SDUM=OLDFLAIR in the GLOBAL card. If by chance, a user
  needs to use those expressions AND some deprecated body types
  (see the previous warning) at the same time, the special SDUM=OLDFLBDY
  is available for this purpose
   Please note that FLUKA offers the possibility to code expressions
  *DIRECTLY IN THE INPUT FILE*, through the #define directive.

-- Modifications to user-written source.f routines
   Due to the new treatment of isomeric states, three new variables have
   to be initialized in the stack: EEXSTK, TMNSTK, ILVSTK.
   Users should modify their custom source.f routines accordingly,
   setting the variables as in the new source.f template.

-- Old residual nuclei output files
   As described above, the auxiliary programs (usrsuw and usrsuwev in
   $FLUPRO/flutil) that sum and process the residual nuclei output files
   depend on the nuclear database. Users who still need to process files
   produced with previous fluka versions can do it by keeping their
   fluka2011.2x distribution. Users who already produced xxx_tab.lis
   and xxx_sum.lis files are not concerned.


This version of the code should be run on the platforms for which it
has been released, that is Linux x86 under g77 (which runs on both
32 and 64 bit machines) and Linux x86_64 under gfortran. The latter
requires a recent version of the gfortran compiler, given the
incompatibility between different versions of gfortran.
A Mac OS version compiled with gfortran is also available.
The available gfortran versions are compiled with gfortran 9.2 (Linux) and
gfortran 9.2 (Mac). Files compiled with gfortran 8.4 (Linux) and
gfortran 8.3 (Mac) are also available.
Users running on Windows can install fluka in a virtual machine through the
provided dockers scripts (on the website).
The code has been reasonably checked and validated for these
platforms/compilers only. There is no warranty whatsoever that the
code and/or the compilers used are bug free, see the disclaimer in the
license file for further details.

The availability of the source code shall not be exploited for tentative
builds on other architectures or with different compilers/compiler options
than the ones recommended by the development team. Our experience shows that
for a code of the complexity of FLUKA the chances of hitting one or more
compiler issues are pretty high. Therefore users shall not make use
for every serious task, including whichever form of publication or
presentation, of code versions built on platforms and/or with compiler
options which have not been cleared as safe by the development team.


The gfortran (64 bits) version is for x86_64 machines and cannot be run
on 32 bit architectures. The FLUKA scripts recognize which version the
user is running according to the following:

a) The FLUFOR environmental variable, which can take the values "g77"
   or "gfortran"
b) If FLUFOR is not set, if the directory name contain the "gfor" string
   gfortran is assumed, g77 otherwise
c) If gfortran is selected by means of a) or b), the additional variable
   GFORFLU can be set to specify the specific version of gfortran to be
   used if more than one is available. Please note that gfortran >= 6.3
   is required. For example, if on your machine "gfortran" points to a
   version < 6.3, and "gfortran63" points to version 6.3, you can set
   GFORFLU to "gfortran63" and happily use the FLUKA gfortran (64 bits)


Use of FLUKA must be compliant with the FLUKA user license, which is
not a GPL-like license. Therefore, users shall read carefully the
licensing conditions as available in the distribution tar file,
on the FLUKA website and in the output files.
In case of doubts or need for special authorizations, or anyway for
licensing and commercial questions, or questions related to publications
or releases, users shall contact the Fluka Scientific Committee (FSC)
(fsc_at_fluka.org) .


The use of the FLUKA code must be acknowledged explicitly by quoting
at least two of the following set of references

    - T.T. Bohlen, F. Cerutti, M.P.W. Chin, A. Fasso`, A. Ferrari, P.G.
      A. Mairani, P.R. Sala, G. Smirnov, and V. Vlachoudis,
      "The FLUKA Code: Developments and Challenges for High Energy and
      Medical Applications", Nuclear Data Sheets 120, 211-214 (2014)

    - A. Ferrari, P.R. Sala, A. Fasso`, and J. Ranft,
     "FLUKA: a multi-particle transport code",
      CERN 2005-10 (2005), INFN/TC_05/11, SLAC-R-773

Use of Flair must be acknowledged using the following reference:

    - V. Vlachoudis, Proc. Int. Conf. on Mathematics, Computational
      Methods & Reactor Physics (M&C 2009), Saratoga Springs, New York, 2009

Additional FLUKA references can be added, provided they are
relevant for the problems under consideration, in particular
the use of some specific models should be individually acknowledged, eg:

For the use of the neutrino event generator (NUNDIS):

    - G. Battistoni, A. Ferrari, M. Lantz, P. R. Sala and G. I. Smirnov,
       "A neutrino-nucleon interaction generator for the FLUKA Monte Carlo
       Proceedings of 12th International Conference on Nuclear Reaction
       Mechanisms, Varenna, Italy, 15-19 June 2009,
       CERN-Proceedings-2010-001 pp.387-394.

For the use of (the modified) rQMD-2.4:

    - H. Sorge, H. Stoecker, and W. Greiner, Annals of Physics 192, 266
    - V. Andersen. F. Ballarini, G. Battistoni, M. Campanella, M. Carboni,
      F. Cerutti, A. Empl, A. Fasso`, A. Ferrari, E. Gadioli, M.V. Garzelli,
      K. Lee, A. Ottolenghi, M. Pelliccioni, L.S. Pinsky, J. Ranft, S.
      P.R. Sala, and T.L. Wilson,
      "The FLUKA code for space applications: recent developments"
      Advances in Space Research, 34(6), 1302-1310 (2004).

For the use of DPMJET-3:

    - S.Roesler, R.Engel, J.Ranft: "The Monte Carlo Event Generator
      in Proceedings of the Monte Carlo 2000 Conference, Lisbon, October
      2000, A. Kling, F. Barao, M. Nakagawa, L. Tavora, P. Vaz eds.,
      Springer-Verlag Berlin, 1033-1038 (2001).
    - A. Fedynitch, PhD Thesis,

For medical applcations of FLUKA:

    - G. Battistoni, J. Bauer, T.T. Boehlen, F. Cerutti,
      M.P.W. Chin, R. Dos Santos Augusto, A. Ferrari, P.G. Ortega,
      W. Kozlowska, G. Magro, A. Mairani, K. Parodi, P.R. Sala, P. Schoofs,
      T. Tessonnier, V. Vlachoudis,
      "The FLUKA code: An accurate simulation tool for particle therapy",
      Frontiers in Oncology, Radiation Oncology Section, 00116 (24 pages)

Paola Sala
INFN Milano
tel. Milano +39-0250317374
tel. CERN +41-227679148

You can manage unsubscription from this mailing list at https://www.fluka.org/fluka.php?id=acc_info
Received on Fri Jan 17 2020 - 12:09:35 CET

This archive was generated by hypermail 2.3.0 : Fri Jan 17 2020 - 12:09:39 CET