Re: [AMBER-Developers] Occasional failures in pmemd serial

From: David A Case <>
Date: Thu, 14 Mar 2013 19:39:09 -0400

On Thu, Mar 14, 2013, wrote:
>Following the developers' meeting and the emergence of the "domdec" branch
>of pmemd, I'm looking at the state of the CPU code and trying to clear up
>some things as we work to make that one competitive against its
>counterparts in Gromacs and now CHARMM.

>...did Monte Carlo barostat initialization perhaps
>set this off, even if the barostat is not ultimately used?).
>In any case, I just want to make sure that I have a strong reference
>before I start hacking.


Be sure to keep Antti-Pekka Hynninen <> in the
loop here; I'm not sure that he is subscribed to Amber-developers. (cc-ing
him here.)

My understanding is that the pmemd_domdec branch is primarily for
Antti-Pekka's use (as least for now); you should probably create your own
branch if you want to start hacking pmemd.

Jason and Ross may be able to comment on the test case errors--did these just
begin this week?

[I'd personally vote to give the Langevin integrator in mdgx higher
priority, and will try to sit down with you to work on that. It still
might be that we should go straight to leapfrog, and a pmemd-compatible
implementation of reading a restart file. Then we could much more
straightforwardly debug against pmemd.]

>First order of business will be to special-case the scalar_sum and
>scalar_sumrc functions to compute pot_enes and virials only when
>requested, in line with the special-casing that happens in the direct
>space sum. It's a small cost in the overall run time, but it's chiseling
>away at something that a few of the processors end up spending a
>significant amount of their time on, so it's one of those things that
>should help us in the long run.

OK...but with several people now suddenly excited about working on pmemd
efficiency, let's redouble efforts to avoid stepping on each other's toes.


AMBER-Developers mailing list
Received on Thu Mar 14 2013 - 17:00:03 PDT
Custom Search