Sorry -- I should have been more clear: the problem is not that the
stream of numbers is non-deterministic. The problem is that often people
write code that does things differently on different nodes (e.g. does
some computation on the master node that's not carried out on the other
nodes). If these things involve accessing the random number generator,
then although all nodes see the same sequence, they are at different
locations within that sequence, so when each node gets the "next" number
in the sequence, they don't all have the same number. If you assume or
enforce that all nodes must access the random stream the same number of
times, this isn't a problem, but I felt that would be a fragile
assumption that would lead to recurrent bugs with constant pH.
Hope that's more clear,
John
On Tue, 2005-05-24 at 10:59, Robert Duke wrote:
> Folks -
> Maybe there are some issues I am unaware of here, but a sequence of
> pseudorandom numbers, starting with the same initial seed, should be
very
> deterministic, and I don't immediately see the problem with relying on
that.
> The only way I could see problems, given that the code is all provided
in
> the app (as opposed to in libraries), would be if you had a
heterogeneous
> parallel run; ie., you were running on different types of platform.
That of
> course would be disastrous, but I can think of lots of things that will
> break if you do that (anywhere you rely on the same calculation on
different
> nodes producing the same result).
> Regards - Bob
>
> ----- Original Message -----
> From: "John Mongan" <jmongan.mccammon.ucsd.edu>
> To: <amber-developers.scripps.edu>
> Sent: Tuesday, May 24, 2005 1:45 PM
> Subject: Re: amber-developers: weirdnesses in Langevin dynamics code
>
>
> >> John Mongan has code for multiple "streams" of random numbers (I
think),
> >> that
> >> might be implemented here. But basically, there is probably nothing
> >> wrong
> >> with the code as it stands.
> >
> > Yes, I reorganized amrand a couple years ago such that it's fairly
easy to
> > create your own "private" sequence of random numbers. Hopefully it's
clear
> > how to use it from the code, or the constant pH code can be used as an
> > example; if not, I'll explain.
> >
> > Constant pH needs to be able to generate the same random number on all
> > nodes so that the Monte Carlo step can be synchronized without needing
MPI
> > comms (I gather that NEB has a similar requirement). I ended up
> > implementing the "private streams" approach because depending on the
main
> > generator to remain synchronized between nodes seemed to be a fragile
> > solution.
> >
> > John
> >
>
Received on Wed Apr 05 2006 - 23:49:56 PDT
