Hi Carlos,
Sorry, but I don't understand the problem here... Changing the processor
count should have close to zero impact on what is happening in the runs (not
completely true, as increasing the processor count probably does ever so
slightly increase rounding error in the force summation). In the case of
the restart files, unless there is a disaster the only one you should be
interested in ever is the last one written, always the last step executed.
So perhaps there is additional grief with things like REMD or LES that you
are more involved with? I need to understand why you would say this, so I
can understand and attempt to fix any real limitations.
Regards - Bob
(I change processor count all the time, really...)
----- Original Message -----
From: "Carlos Simmerling" <carlos.simmerling.gmail.com>
To: "AMBER Mailing List" <amber.ambermd.org>
Sent: Tuesday, December 15, 2009 8:31 AM
Subject: Re: [AMBER] Number of Cycles
> the automatic scaling is great but people should be careful not to change
> processor count during a project - which I often do based on partition
> availability at run time. it can make things very confusing later.
>
>
> On Tue, Dec 15, 2009 at 8:23 AM, Robert Duke <rduke.email.unc.edu> wrote:
>
>> And I forgot to mention, but of course if you actually specify a value
>> for
>> ntwr in &cntrl, that value overrides the "default"
>> scaled-by-processor-count
>> value in pmemd. Actually, a great way to screw performance in pmemd is
>> to
>> specify some small number for ntwr and then throw your job at a couple
>> hundred processors... So I don't recommend putting a value for ntwr into
>> &cntrl unless you have a reason.
>> Regards - Bob Duke
>> ----- Original Message ----- From: "Robert Duke" <rduke.email.unc.edu>
>> To: "AMBER Mailing List" <amber.ambermd.org>
>> Sent: Tuesday, December 15, 2009 8:16 AM
>> Subject: Re: [AMBER] Number of Cycles
>>
>>
>> I presume that for sander there is indeed a simple "default" ntwr value,
>>> giving a rewrite every 500 steps. In pmemd, the value is actually
>>> scaled as
>>> a function of processor count once you have more than 10 processors, in
>>> order to not increase the frequency in time of rewriting restart files
>>> as
>>> you run on more and more processors. This keeps you from getting into a
>>> situation where writing this file has a significant performance impact.
>>> Regards - Bob Duke
>>> ----- Original Message ----- From: "Jason Swails"
>>> <jason.swails.gmail.com
>>> >
>>> To: "AMBER Mailing List" <amber.ambermd.org>
>>> Sent: Tuesday, December 15, 2009 7:10 AM
>>> Subject: Re: [AMBER] Number of Cycles
>>>
>>>
>>> Hello,
>>>
>>> The exact step that the MD died on is fairly irrelevant. The only
>>> thing that really matters is the last step of the MD in which a
>>> restart file was written (this is ntwr, which has a default of 500 I
>>> believe). If ntpr is greater than ntwr (especially by multiples of
>>> ntwr), then there is no way of isolating exactly which step your
>>> calculation ended on. This is why I typically use the same values for
>>> ntwr and ntpr (and ntwx for MD simulations). If you do use the same
>>> value for ntwr and ntpr, and the last step printed for ntpr is 66000,
>>> then your restart corresponds to MD step 66000, and you'll need to run
>>> an additional 34000 steps to reach 100000 (66000 + 34000 = 100000).
>>>
>>> Hope this helps!
>>> Jason
>>>
>>> On Tue, Dec 15, 2009 at 3:31 AM, s. Bill <s_bill36.yahoo.co.uk> wrote:
>>>
>>>> Dear AMBER
>>>> How can I complete my total number of cycles?
>>>> Say, I had submitted my job for 100000 cycle (nstlim=100000), and due
>>>> to
>>>> the wall clock time my job stopped at cycle number 66000, I asked to
>>>> write
>>>> out the output every 5000 cycle (NTPR=5000, NTWX=5000). The problem
>>>> here is
>>>> how to complete the remaining steps. I am not sure if the remaining
>>>> steps
>>>> are 44000, it may be in between 44000 and 43500, where my output
>>>> written
>>>> every 5000.
>>>> So, how can I complete my number of cycles? is there any keyword manage
>>>> this problem?
>>>> Thanks in advance
>>>> S. Bill
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> AMBER mailing list
>>>> AMBER.ambermd.org
>>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>>
>>>>
>>>
>>>
>>> --
>>> ---------------------------------------
>>> Jason M. Swails
>>> Quantum Theory Project,
>>> University of Florida
>>> Ph.D. Graduate Student
>>> 352-392-4032
>>>
>>> _______________________________________________
>>> 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
>
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Dec 15 2009 - 07:00:04 PST
