Respin fluka2011.2-10 released

From: Alfredo Ferrari <alfredo.ferrari_at_cern.ch>
Date: Sun, 22 Jan 2012 16:08:50 +0100

Dear Fluka users

fluka2011.2-10 has been just pushed to the web site. It is a bugfix
respin, which tackles a few, rare, minor issues which are listed below,
together with those fixed by fluka2011.2-9 which was never properly
announced. Most of these (rare) issues are related to the use of neutrino
interactions. One of them (f)) is trying to address a misunderstanding
about the use of the usimbs.f routine

a) an issue when using the PEANUT generator up to high energies with
     immediate charmed particle decays inhibited (see PHYSICS card)
     has been fixed (fluka2011.2-9)
b) a very rare crash in the high energy event generator has been
     fixed: this fix potentially *changes* the random number sequence
     (fluka2011.2-9)
c) a possible (rare) random number sequence non reproducibility bug
     in the high energy generator has been fixed. Obviously this fix
     potentially *changes* the random number sequence (fluka2011.2-9)
d) an issue with improper printout formats when asking for neutrino
     interactions has been fixed. While this bug was resulting in a
     somewhat garbaged preliminary beam printout on g77 with no
     further consequence, it was crashing gfortran (fluka2011.2-10)
e) an issue which could result in crashes when asking for hadron single
     scattering everywhere in a region has been fixed (fluka2011.2-10)
f) a protection has been built into the code to tackle with non standard
     user-defined importance biasing (those using usimbs.f). A recent post
     to the discussion list was making use of a constant splitting factor
     *regardless* of any check on the particle position (eg if it was or not
     passing a given x,y,z, or whatever). I would like to remind that user
     defined importances are valuable in order to avoid to sub-segment
     the geometry. They are NOT supposed to work with constant factors
     independent on the performed step, regardless whther it is 1 um
     or 1 km. In this way they can introduce a not-so-subtle bias on the
     results. To better explain, a possible usimbs.f aiming at user defined
     splitting as a function of radius, say every cm, should check if the
     last setp resulted in crossing a "1 cm" boundary (eg form 2.7 to 3.3
     or similar) and in that case issue a factor different from one.
     Anyway in order to protect from pathological uses, some extra
     safety has been introduced into the code. The example sent to
     the list now works correctly (even though is not reasonable according
     to the discussion above) and results are unbiased (fluka2011.2-10).
g) A modification has been introduced in the usbmax.c auxiliary code
     in order to improve the corresponding capability in Flair
     (fluka2011.2-10). More details will come from Vasilis: a new version
     of flair compatible with the new usbmax.c is being pushed to the web
     site

                Ciao
           The FLUKA developer team

+----------------------------------------------------------------------+
| Alfredo Ferrari || Tel.: +41.22.76.76119 |
| CERN-EN/STI || Fax.: +41.22.76.69474 |
| 1211 Geneva 23 || e-mail: Alfredo.Ferrari_at_cern.ch |
| Switzerland || |
+----------------------------------------------------------------------+
Received on Sun Jan 22 2012 - 19:45:05 CET

This archive was generated by hypermail 2.2.0 : Sun Jan 22 2012 - 19:45:13 CET