From: sonia ziada (sonia.ziada_at_univ-orleans.fr)
Date: Tue Nov 15 2016 - 01:34:34 CST
Hello,
Ok. Thank you very much for your responses.
Sonia.
On 11/14/2016 09:46 PM, Brian Radak wrote:
>
> I think the magic number is 50 for now (last I read the source code
> anything less than this should give a friendly warning).
>
> You /might/ be able to track performance based on IO frequency (as in
> plot a positive slope line of ns/day vs print step that should
> eventually plateau). I have seen this be appreciable in other GPU
> codes such as pmemd.CUDA, but NAMD has a rather different design from
> those codes, so the effect may not obviously materialize.
>
> On 11/14/2016 02:30 PM, Chris Goedde wrote:
>> On Nov 14, 2016, at 2:24 PM, Brian Radak<bradak_at_anl.gov> wrote:
>>> This is only a partially informed answer, but I believe the answer is yes. Specifically I'm pretty sure the targeted MD calculations require a CPU only computation at each cycle - this will be considerably slower than other MD methods.
>>>
>>> In general, anything that requires a system-wide calculation (such as the energy or some collective variable) will drastically reduce performance. You will notice that this also holds for high frequency I/O (e.g. setting outputEnergies to a small value).
>> That’s interesting. Does that also apply to dcdFreq and friends?
>>
>> Also, what’s considered “small” in this case? If I’m running for 10^7 time steps, is small 10^4, 10^5, … ? Some guidance would be useful before I start experimenting willy-nilly.
>>
>> Chris
>>
>>
>
> --
> Brian Radak
> Postdoctoral Appointee
> Leadership Computing Facility
> Argonne National Laboratory
>
> 9700 South Cass Avenue, Bldg. 240
> Argonne, IL 60439-4854
> (630) 252-8643
> brian.radak_at_anl.gov
This archive was generated by hypermail 2.1.6 : Sun Dec 31 2017 - 23:20:48 CST