From: sonia ziada (sonia.ziada_at_univ-orleans.fr)
Date: Tue Nov 15 2016 - 01:34:34 CST
Ok. Thank you very much for your responses.
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.
> Brian Radak
> Postdoctoral Appointee
> Leadership Computing Facility
> Argonne National Laboratory
> 9700 South Cass Avenue, Bldg. 240
> Argonne, IL 60439-4854
> (630) 252-8643
This archive was generated by hypermail 2.1.6 : Tue Dec 27 2016 - 23:22:36 CST