RE: Random seed (RANDOMIZE)

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 Sun Jul 03 2011 - 19:47:44 CEST