Re: Random seed (RANDOMIZE)

From: Chris Theis <>
Date: Fri, 1 Jul 2011 20:46:21 +0000

Dear Paola,

Parallelising transport MC is surely not trivial from a technical point
of view, but it can be done applying for example asynchronous SPMD
approaches as demonstrated by PENELOPE, MCGPU or also many other codes
in the CG domain. The feasibility strongly depends on the underlying
code design.

Unfortunately I won't be able to join you on Monday but I'm surely
willing to contribute within the boundary conditions set by my other
professional obligations.


On 1 Jul 2011, at 16:54, "Paola Sala" <> wrote:

> Dear Chris,
> maybe I'm naive too,
> but to my poor knowledge transport Monte Carlo are not so easy to
> parallelize. You can surely find literature on this subject, but the
> trivial reason is that there is no fixed length loop to
> parallelize. Every history, and every substep in a history, involves
> an unpredictable and widely varying number of different operations.
> Fake parallelization, i.e. parallel runs on different cpus, are of
> course not so elegant but they are staightforward, sure and efficient.
> Now, of course one can think of an automatic way of preparing,
> running, summing up several parallel runs. This is one of the
> technical improvements that we wish to implement. I hope you'll be able=
> participate to the next collaboration meeting, where the item will
> be discussed, and of course any contribution from your side would be
> welcome.
> Ciao
> Paola
>> Alberto,
>> thanks for your quick answer on this quite interesting& lively
>> discussion.
>> I take your point on the matter of philosophy& compatibility of
>> suggestions.
>> But I would like to stress once again that my proposal does not at all
>> imply
>> any change of philosophy but only a reversal of what is considered as
>> default/optional and a bit of automatized help for the user!
>> As I wrote in each previous e-mail the reproducability of pseudo-random
>> numbers is crucial - this is a point that I have never questioned.
>> However, I
>> stand by my opinion that for a user this is in most cases not of concern=
>> If the code generated the initial random seeds by itself, while outputti=
>> the first one, then the user would not have to worry about correctly
>> initiating FLUKA's way of parallelization himself, while retaining the
>> possibility
>> to fully reproduce the random sequence which was "chosen" by the machine=
>> The way that the seed is generated originally is something which can be
>> done via hardware
>> - like I said with VIA mobos for example - or deterministic master-slave
>> mechanisms
>> as long as the disjointness of parallel sequences is preserved and the
>> initial
>> seed is available for later use to reproduce the pseudo-random sequence.
>> If this approach, for which I do not claim authorship but which has been
>> devised
>> and discussed in a plethora of mathematical treatments over the last
>> decades,
>> is naive, is something that might lie in the eye of the beholder.
>> Yet, it is a popular and widely successful approach implemented in vario=
>> Monte Carlo codes, a technique that extends far beyond the domain of
>> radiation transport.
>> So what I do object against is the statement that it is un-workable.
>>> Referring to what I have said above, your idea of what a default should
>>> be conflicts hardly with the FLUKA philosophy that all jobs should
>>> be reproducible.
>> Well, this is a philosophical design question which can be argued about.
>> But
>> you are absolutely right that in any case it is the developer's decision=
>> no matter if the users like it or not.
>> However, this discussion hides a probably much more interesting and
>> important aspect regarding parallelization. In times of N-core CPUs and
>> GPGPUs,
>> found even in cell-phones, the question is rather why a user has to do
>> parallelization& distribution himself? This surely is a philosophical
>> question
>> which I would be interested to hear your opinion about.
>> Ciao
>> Chris
>> ________________________________________
>> From: Alberto Fasso' []
>> Sent: 29 June 2011 19:13
>> To:
>> Cc: Chris Theis; Alfredo Ferrari; denis bertini
>> Subject: RE: Random seed (RANDOMIZE)
>> Two answers, one to Chris and one to Denis. In both cases, I ask you to
>> keep
>> in mind that every Monte Carlo code is designed according to a particula=
>> "philosophy", that you may like or not. Suggestions to do modifications
>> are ok, but not if they are incompatible with that philosophy.
>> On Wed, 29 Jun 2011, Chris Theis wrote:
>>> with all due respect but I beg to differ on this point. The approach
>>> that=3D
>> I
>>> describe is nothing new and actually implemented in various Monte Carlo
>>> codes,
>>> admittedly in the CG domain, but this is not of concern for this
>>> discussion.
>>> The approach is simply to revert the default behavior that FLUKA
>>> currently
>>> exhibits. So mathematically nothing changes at all. More specifically,
>>> it
>>> would mean deterministic selection of predefined seeds as an option for
>>> debugging and development, while starting from (pseudo)random seeds as
>>> a
>>> default. However, this does not mean that the user would be prevented
>>> from
>>> selecting a seed himself, but he would not be forced to do so to get
>>> independent runs. It is true that mathematically it cannot be fully
>>> excluded
>>> that the same seed would be re-used if generated in a pseudo-random
>>> manner,
>>> but given the periodicity of modern RNG or the application of for
>>> example a
>>> VIA mobo the probability can be kept at an almost zero level.
>> Chris, your proposal would make impossible for anybody to help a user wh=
>> has got a problem, or to find a rare programming bug in the code.
>> Reproducibility of random numbers is as important as their independence,
>> and
>> probably more. This was realized by Monte Carlo developers since the ver=
>> early times: the first generators produced numbers completely independen=
>> obtained from electronic noise measurements, and they were soon abandone=
>> because they were not reproducible.
>> Referring to what I have said above, your idea of what a default should =
>> conflicts hardly with the FLUKA philosophy that all jobs should be
>> reproducible
>> (see for instance the care taken about overlapping ORs in the geometry).
>>> Alfredo Ferrari wrote:
>>> I believe Denis question is different, if I understand correctly he
>>> would like
>>> to have a way through a user routine to input something equivalent to
>>> what is
>>> now input in what(2) of RANDOMIZe? Am I correct?
>> It is difficult to understand why making a copy of an input file should =
>> more complicated than writing, compiling and writing a user routine.
>> The fact that GEANT does it this way is coherent with the fact that all
>> GEANT input is programmed by the user. FLUKA has been written with the
>> opposite
>> philosophy: that the user should program nothing or as little as possibl=
>> All that can be done with an input file shall be done with it.
>> Alberto
> Paola Sala
> INFN Milano
> tel. Milano +39-0250317374
> tel. CERN +41-227679148
Received on Sat Jul 02 2011 - 13:19:48 CEST

This archive was generated by hypermail 2.2.0 : Sat Jul 02 2011 - 13:19:48 CEST