I mean that if changing processor count changes ntwx, then you need to be
very careful in a project with multiple trajectory files since the time per
frame increment is not constant. correct?
I don't mean the data will be wrong, just that one must be careful in
processing the data, such as when combining multiple trajectory files.
that's why I said it can be confusing- not incorrect.
On Tue, Dec 15, 2009 at 9:55 AM, Robert Duke <rduke.email.unc.edu> wrote:
> 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
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Dec 15 2009 - 09:00:03 PST
