RE: Random seed (RANDOMIZE)

Hi Chris,

I wish not to expend further bandwidth on this, but just to clarify to the
wider fluka-discuss community:

There's a gulf of difference between RANDOMIZ's WHAT(2) and the seed.
WHAT(2) is as simple as 1, 2, 3; it is fool-proof. Seeds are of funny
numbers. That is why WHAT(2) is in place -- to mask dangerous exposures.

Monte Carlo simulation of radiation transport is naturally parallel, as
mentioned earlier. Slicing up the task orthogonally against its nature
would make no difference to the user -- except that it makes simulations
even longer due to cross-talk (forced and unnecessary) overhead. The only
possible advantage I can think of is when we have more cores than the
total number of histories, eg. we have 8 cores and we need strictly no
more than 7 histories.

Stopping here, as I have a sneaky feeling that the fluka-discuss moderator
would consider exercising his spam filter.

Cheers!

:) mary

On Sun, 3 Jul 2011, Chris Theis wrote:

> Hi Mary,
>
>> Multicores, multi-threads etc have been great advances indeed, particularly for gaming, CG eg. real-time graphics rendering for immersive-
>> experience / 4D cinemas....
>
>> The above apps differ from computational Monte Carlo radiation transport in two fundamental ways:
>> 1) they do not iterate over many instances of similar small jobs ('histories' in our case of Monte Carlo)
>> 2) their jobs cross-talk eg they render graphics according to the data queried. (In our case there is=20
>> absolutely no cross-talk between histories.)
>
> your arguments are to some extent correct for the specific applications you
> cite. However, also in the CG domain you do find MC transport applications
> of which some are parallelized and fit exactly the criteria that you give.
> Having worked in the CG industry as a software designer for more than 10
> years on exactly these aspects I will be happy to give you a number of
> examples + more technical details in case you want. But I think this leads too
> far off-topic for a discussion on this list.
>
>> Not needing message-passing is an advantage! Because this is the limiting factor.
>
> I fully agree and that's exactly why I mentioned asynchronous (!) SPMD as
> a possibility for parallelization. However, it is of course only possible
> to retro-fit if the code's design is compatible, which according to Alberto
> it isn't. So of course I take his word on this matter as without doubt he
> is among the people who have the best insight into the code.
>
>> WHAT(2) is not a seed as much as its counterparts in EGSnrc, MCNP, G4 and PENELOPE input files aren't.=20
>
> If you check out ENTRY FL64IN() in the code you will see that WHAT(2) is
> indeed a seed. Together with a second counter-part it is used to initialize
> a vector of 97 seeds, which are then used to generate random sequences. So
> it's not the direct seed for each sequence but its value determines the values
> of those 97 seeds.=20
>
>> On the other hand, 'everyone' has a script to generate multiple input files, each with a different sequence initializer, and to collect the harves=t at the end. Admittedly, most > > of us do it with a few lines of scripts, of no comparable scale to the 'interface' you deveoped.
>> [from the user's point of view it would be more flexible if the user did not have to input different seed]
>
>> I am still surprised. I have been a user all these codes for many years but I have never touched a single seed in my life.
>
> I am actually surprised that in science users very often do not mind having
> to run or build multiple scripts to generate more scripts and files to solve
> things that are most efficiently and least error prone solved by an all-in-one
> solution. Interestingly enough the same users readily adapt to more comfortable
> solutions once they are available. Of course everybody is entitled
> to do things his/her way, using whichever solution they deem most efficient.
> However, you only need to look at the popularity that FLAIR enjoys, which
> basically does what you could have done yourself in former times with a text
> editor + your favorite plotting tools. So why use it? Because it does
> it in a nicer, quicker, easier and safer way and that's IMHO the reason for
> its success. Especially, in the software domain you find numerous similar
> examples. Yet, there are without doubt many ways to get a job done.
>
> Cheers
> Chris
>
>
Received on Tue Jul 05 2011 - 23:20:56 CEST