John -
Understood. I am more used to dealing with development in an environment
where I know who the heck is calling random number generators. Perhaps a
better way to handle this would be to effectively "objectify" it. In f90,
one could define a record structure with all the necessary state data for
the random number generator. One would then call the random number
generator, always passing in a pointer to the appropriate state record
associated with a given task. In this manner, you could run however many
random number sequences starting with whatever seed you want. Of course,
this would be much more intuitive with a c++ object, but the basic idea is
still realizable in fortran (perhaps in a neater manner than this first
suggestion; I tend to not get really esoteric in my use of language
features).
Regards - Bob
----- Original Message -----
From: "John Mongan" <jmongan.mccammon.ucsd.edu>
To: <amber-developers.scripps.edu>
Sent: Tuesday, May 24, 2005 3:39 PM
Subject: Re: amber-developers: weirdnesses in Langevin dynamics code
> 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
