From: Brian Radak (bradak_at_anl.gov)
Date: Mon Nov 14 2016 - 14:46:40 CST
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 : Tue Dec 27 2016 - 23:22:36 CST