Re: Fluka2008 - manual setting of max. particles in source routine

From: Alfredo Ferrari <>
Date: Tue, 10 Feb 2009 21:39:10 +0100

Hi Chris

Alberto already told you the correct way of doing this. Changing NCASES
"on the fly" was never supposed to be the way for this task, it worked by
chance. The source routine always had the "NOMORE" argument for this.
It was not explicitly mentioned in the routine comments, but it is
explained in the manual: I just updated the comments of the dummy source.f
to make it easier for users to know about.

I suppose this solves your issue.

I would like to profit from this discussion in order to warn once more
users about situations where source particles are read from pre-generated
files. Obviously there are many situations where this procedure is
unavoidable (I have a lot of examples myself). It is important that people
realizes two possible issues:

a) whenever possible particles should be selected RANDOMLY from the
    the pregenerated file, NOT SEQUENTIALLY. This is particularly
    important when the number of requested particles is such to
    imply the (re)use of filed particles more than once. In this
    situations, sequential reading of the file will end up in possible
    artefacts, implicitly biasing the source term. But even when the number
    of requested particles is less or equal than the particles on files,
    random selection is statistically much more sound than sequential
    reading. the latter can give the false impression that one is not
    biasing the pregenerated results, but in reality it is not better
    than random selection, rather the opposite. Think about a Poisson
    distribution where you start from all the 0's, then the 1's etc
    instead of randomly sampling. In my opinion, the only case where
    sequential selection is perhaps harmless is when the requested
    number of particles is exactly the same as the number of particles on
b) statistical errors are ALWAYS WRONG when an external, pregenerated file
    is used. The limiting example is a file with just few particles that
    you repeat again and again. Statistics will rapidly converge to fake
    small errors, while of course real errors will be dominated by the
    paucity of the initial file. There is no simple way around this issue,
    the user has to apply considerable wisdom and expertise in judging
    the statistical robustness of the results of simulations based
    on pregenerated source files


| Alfredo Ferrari || Tel.: + |
| CERN-EN/STI || Fax.: + |
| 1211 Geneva 23 || e-mail: |
| Switzerland || |

On Fri, 6 Feb 2009, Alberto Fasso' wrote:

> Hi Chris,
> even before, setting NCASES = NCASE was not the most elegant way
> to terminate the run. It worked, but it was not guaranteed, as you
> have just found out.
> There are other "non-elegant ways" to do it: for instance I have
> sometimes opened with success a fluka.stop file.
> But I don't recommend it: these are dirty tricks. The regular way is to
> set NOMORE = 1. This variable is not in COMMON
> either, but it is the only argument of the SOURCE calling list.
> It is transferred back to routine FEEDER, which stops "feeding"
> particles and returns to FLUKA main for final output.
> Alberto
> On Fri, 6 Feb 2009, Chris Theis wrote:
>> Dear developers,
>> we've recently discovered that the manual setting of the maximum number
>> of particles inside the source routine does not work anymore with Fluka
>> 2008. In previous versions it was possible to enforce a premature but
>> clean termination of a run by setting NCASES in the source routine to
>> the current number of the started particle. With Fluka 2008 this
>> approach seems to be broken as the loop termination condition of the
>> feeder now triggers on ANCASS. Unfortunately, this variable is not
>> included in a common block in contrast to NCASES and thus, any
>> modification in the source routine will not propagate to the feeder.
>> For 2-step routines which have to set the maximum number of particles
>> dynamically during the runtime (e.g. based on a phase-space file which
>> is loaded) this functionality is critical in order to avoid manual
>> intervention by the user which could be rather error prone. Is there
>> any other way which is recommended now to terminate the current cycle,
>> based on a runtime condition, or would it be possible to include ANCASS
>> in a common block?
>> Thanks a lot for your help!
>> Cheers
>> Chris
>> ------------------------------------------------------------------------
>> Chris Theis
>> CERN/DG-SC - European Organization for Nuclear Research
>> 1211 Geneva 23, Switzerland
>> Phone: +41 22 767 8069 Office: 892-2A-015
>> e-mail: www:
>> ------------------------------------------------------------------------
> --
> Alberto Fasso`
> SLAC-RP, MS 48, 2575 Sand Hill Road, Menlo Park CA 94025
> Phone: (1 650) 926 4762 Fax: (1 650) 926 3569
Received on Tue Feb 10 2009 - 22:17:40 CET

This archive was generated by hypermail 2.2.0 : Tue Feb 10 2009 - 22:17:40 CET