[gmx-developers] Performance checklist

[Mark Abraham]

On 13/10/2012 12:35 AM, Shirts, Michael (mrs5pt) wrote:
> Hi, all-
>
>> I added a performance check-list on the Gromacs site:
>> http://www.gromacs.org/Documentation/Performance_checklist
> The one concern I have about recommending 4 to 5 fs steps for virtual sites
> is that the ambiguity about what the real kinetic energy is (because we are
> using estimators for the kinetic energy when we use either leapfrog or
> verlet) becomes worse as the step size becomes larger. This means the fact
> that a system reports itself to be at the correct temperature is not
> necessarily conclusive.
>
> This is a situation where going through and doing an ensemble check to make
> sure the potential energy distributions are properly valid for the desired
> temperature would be a good study to do -- I'm happy to help someone set one
> up using the checkensemble tools I've developed, though I don't have the
> time to do it all myself.  Of course, maybe I've missed some careful checks
> that have been done on that system in the meantime, and this level of
> checking has been done already.

I'd like to set up this sort of testing to be automatic and easy, and 
have been using Michael's gear for some other work; ideally, these would 
run via Jenkins. The heavy lifting for 5.0 could break just about 
anything, and my experience of catching problems with feature X not 
working with option Y (e.g. md-vv with v-rescale thermostat in 4.5.x, 
http://redmine.gromacs.org/issues/1000) leads me to the strong opinion 
that a much broader battery of tests is a very sound (overdue?) 
investment. They'd need too much time to run for every commit, but 
catching problems early will be easy and effective with such tests every 
week or two, or when we know a commit is hitting sensitive areas.

The main caveat is that Michael's checkensemble tools require Python and 
numpy and to post-process GROMACS output to .xvg. That's fine and good 
for now, but at some point it could prove worthwhile to get 
checkensemble to read .edr files.

> As a semi-aside, note that some of these concerns might be fixed by
> implementing some sort of hybrid MD/MC.  I'm still arguing for (and ready to
> help organize) for 5.0 a more general integrator class that supports (as
> default) straight MD, but can also handle more generate MC moves, which
> would include hybrid MD and allow relatively large time steps w/o any errors
> in the distribution.

Yes, this is the kind of thing I would also like to see, but AFAICR I am 
yet to hear others' visions for 5.0.

Mark