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
file
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
Ciao!
Alfredo
+----------------------------------------------------------------------+
| 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 || |
+----------------------------------------------------------------------+
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: Christian.Theis@cern.ch www: http://www.cern.ch/theis
>> ------------------------------------------------------------------------
>>
>>
>>
>
> --
> Alberto Fasso`
> SLAC-RP, MS 48, 2575 Sand Hill Road, Menlo Park CA 94025
> Phone: (1 650) 926 4762 Fax: (1 650) 926 3569
> fasso_at_slac.stanford.edu
>
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