Yes, I understand that the thing has deeper "state" than just the last
number (have looked at the code, there are 100 numbers of "state"). So I
understand in theory what you are saying, and don't disagree - very very
high liklihood that the next number you choose is okay, as long as it is a
different number (probably would take work to pick a bad one). But there is
no harm in doing things that are even more likely, though not certain, to
not produce problems, so I tend to err in that direction; in reality we
should really be preserving the state of the rng across runs to just be
sure. People did not believe that problems could occur by reuse of the same
random seed; they were wrong. I actually hesitated to reply to this thing
because I figured someone would jump on me about this; sorry, but time and
again I see people being cocky in this field about cavalier approaches being
okay.
Regards - Bob
----- Original Message -----
From: "Adrian Roitberg" <roitberg.qtp.ufl.edu>
To: "AMBER Mailing List" <amber.ambermd.org>
Sent: Thursday, March 19, 2009 9:30 AM
Subject: Re: [AMBER] IG not change at each restart of NPT simulation
> Bob,
> NONONO.
> Any number is as good as any other number !
>
> The random number generators we use are chaotic vs random seed. What this
> means is that if you change the value of ig by ONE, you get a completely
> different random sequence.
>
> Adrian
>
> Robert Duke wrote:
>> Well, what you want to do is select numbers less likely to repeat the
>> previous last random number sequence. I have not thought about this
>> deeply, but based on something I read somewhere, I believe that choosing
>> prime numbers as seeds has merit. There are great lists of primes at the
>> website primes.utm.edu (thanks to Chris Caldwell); that's what I use.
>> Ultimately we (the amber dev guys, me in particular) should implement
>> code that allows continued sampling from the distribution first used in a
>> run (so, basically, saving the state of the pseudo-random number
>> generator at the end of each "leg" of a run). This unfortunately will
>> entail dinking with the restart file format.
>> Regards - Bob Duke
>> ----- Original Message ----- From: "Rajesh Raju"
>> <Rajesh.Raju.postgrad.manchester.ac.uk>
>> To: <amber.ambermd.org>
>> Sent: Thursday, March 19, 2009 8:54 AM
>> Subject: RE: [AMBER] IG not change at each restart of NPT simulation
>>
>>
>> Hi,
>> I have a doubt... I am using NTT=3 thermostat for my dynamics. after
>> my equilbration I have done production run atNVT ensemble. Should I
>> need to change IG random generator seed for restart. I am doing 2ns
>> with 3-4 restatrs. But dont know how to change ig ...Can i select any
>> number?
>> Cheers
>> Rajesh
>>
>>
>> Quoting "Hopkins, Robert" <hopkins.uhcl.edu>:
>>
>>> Hi Ross,
>>>
>>> Thanks for your prompt and clear reply -- Yes, I'm using NTT = 3, so
>>> I'll be setting IG for each restart!
>>>
>>> Bob Hopkins
>>>
>>>
>>> -----Original Message-----
>>> From: amber-bounces.ambermd.org [mailto:amber-bounces.ambermd.org] On
>>> Behalf Of Ross Walker
>>> Sent: Wednesday, March 18, 2009 6:07 PM
>>> To: 'AMBER Mailing List'
>>> Subject: RE: [AMBER] IG not change at each restart of NPT simulation
>>>
>>> Hi Bob,
>>>
>>>> After trying to follow this thread and reading the Cerutti, Duke, et.
>>>> al. paper, my lack of experience with Amber still leaves me with some
>>>> questions about my restart runs. Here's the problem: if I restart
>>>> after a minimization (or if NTX .lt. 3 .and. TEMPI .ne. 0.0), it is
>>>> clear that the pseudo-random number generator (PRNG)comes into play
>>> and
>>>> I would want to use a new IG each time. On the other hand, I assume it
>>>> is *not* involved with restarting a sander run from a .rst file which
>>>> contains the velocity information. So, if this is not the case, then
>>>> I'd really like to know that.
>>>>
>>>> What is bothering me is that I'm (no doubt, naively) having difficulty
>>>> imagining the situation when one would do a long series of linked
>>>> calculations while resetting the initial velocities at each restart.
>>> In
>>>> this case, the consequences of not specifically changing the IG value
>>> at
>>>> each restart in order to find an initial, 'non-repetitive' set of
>>>> velocities seem apparent. Alternatively, (and the crux of my concern)
>>> it
>>>> may be that the PRNG is used elsewhere (embedded in the Amber code)
>>> and
>>>> the reason for changing the IG value is not explicitly apparent.
>>>
>>> What you are describing is correct if you do not use a thermostat or you
>>> use
>>> a Berendsen thermostat. In this case the random number generator is not
>>> used
>>> unless you are randomly assigning velocities which you do not do on a
>>> restart. However, the paper and the discussion is refering to the case
>>> where
>>> the Langevin thermostat is used (ntt=3) here the random number generator
>>> is
>>> used to drive the Langevin thermostat and it is this situation that
>>> causes
>>> the problems. Since if you keep reusing the same random number stream
>>> you
>>> essentially impart a series of correlated forces on your system which
>>> can
>>> cause all sorts of weird things to happen. Thus if you have ntt=3 you
>>> MUST
>>> change the value of IG for every run including restarts. With AMBER 10
>>> and
>>> later you can set this to -1 and it will use the wallclock time in
>>> microseconds and save you needing to script the change yourself.
>>>
>>> I hope this answers your concerns.
>>>
>>> All the best
>>> Ross
>>>
>>>
>>> /\
>>> \/
>>> |\oss Walker
>>>
>>> | Assistant Research Professor |
>>> | San Diego Supercomputer Center |
>>> | Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
>>> | http://www.rosswalker.co.uk | PGP Key available on request |
>>>
>>> Note: Electronic Mail is not secure, has no guarantee of delivery, may
>>> not
>>> be read every day, and should not be used for urgent or sensitive
>>> issues.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> AMBER mailing list
>>> AMBER.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>
>>> _______________________________________________
>>> AMBER mailing list
>>> AMBER.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>
>>
>>
>>
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>>
>>
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>>
>
> --
> Dr. Adrian E. Roitberg
> Associate Professor
> Quantum Theory Project
> Department of Chemistry
>
> Senior Editor. Journal of Physical Chemistry
> American Chemical Society
>
> University of Florida PHONE 352 392-6972
> P.O. Box 118435 FAX 352 392-8722
> Gainesville, FL 32611-8435 Email adrian.qtp.ufl.edu
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Mar 20 2009 - 01:15:45 PDT
