This is exactly what I tried to do. I'm not all that experienced with F90,
so there may be a better way (I'm open to suggestions/rewrites), but you
can see what I've got in src/sander/random.f
In addition to the object-style interface you've suggested, I also
preserved the original single stream interface by creating wrapper
functions that get the generator state record out of a common block and
then call the "objectified" routines with this default generator record.
This way portions of the code that want to control accesses to their
random stream can keep their own private streams, and other parts of the
code that aren't so picky can continue to use the old interface and don't
have to worry about storing/passing around the generator state data.
random.f was my first experience with F90, so, as I said, there may be
better ways to do this.
Thanks,
John
On Tue, 24 May 2005, Robert Duke wrote:
> 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
