Hi David -
I have actually considered treating water separately, somewhat as you
suggest, but I feel constrained to exactly replicate sander results, which I
sort of doubt you do with low resolution tables. I will definitely consider
something in this vein as long as it produces exact results with sander out
to about 300 steps; there are after all lots of ways I can sacrifice
precision to gain speed. I don't think we necessarily need precision to the
level I am getting it for quality of results - it is more a software
validation issue. But given your comments here, I will give more serious
consideration to a routine handling just the water-water interactions. We
got a big jump in performance for direct force computation going 8->9, I
have been concentrating more on scaling issues as of late, but I do firmly
believe that getting single node performance fast is the first step in
getting overall performance. I think you may also not be considering that
there is real overhead in doing the separation of the two types of atoms -
water vs nonwater, that will lower the performance "yield". But it still is
the kernel of an idea that may help some.
Thanks - Bob
----- Original Message -----
From: "David Cerutti" <dcerutti.mccammon.ucsd.edu>
To: <amber-developers.scripps.edu>
Sent: Wednesday, December 13, 2006 5:43 PM
Subject: amber-developers: How to compute H2O:H2O nonbonded forces 80%
faster than PMEMD9
> I've been playing with lookup tables and linear interpolation for
> nonbonded force computations using a simple, homemade molecular dynamics
> engine that I plan to use to parameterize a new water model. My lookup-
> based non-bonded force computation is considerably faster than AMBER9's
> PMEMD module, and will work for general pairwise potential functions.
> Taking a large box of water as a text case, my computation seems to go
> about 80% faster than PMEMD if I use linear interpolation, and
> cubic-spline interpolation seems like it would incur a minor additional
> cost (overall performance perhaps 70% faster than PMEMD). Bear in mind
> that this enhancement applies to water:water interaction computation only;
> other interactions would be computed in the conventional manner.
> The key to my success was to make lookup tables for each of the
> interactions that might be found in the water, by far the most ubiquitous
> substance in the simulation.
> I re-image the residues based on the location of a "central atom",
> split the primary simulation cell into sub-cells based on the cutoff and
> the maximum size of a water molecule (defined by the rigid O-H bond in my
> case, although one could extend this to work with flexible waters by
> making some assumption that the bond won't stretch more than perhaps
> 0.5A), then replicate the peripheral sub-cells to satisfy PBCs. (I find,
> as you probably know, that this is much faster than computing the PBCs on
> the fly.) I then loop over the sub-cells, determining first whether two
> residues' central atoms (again, the water oxygens) are close enough to
> possibly have atoms within the nonbonded cutoff and, if they are,
> computing their interactions via linear interpolation from finely-spaced
> tables indexed by the squared distance.
> To save some memory, I have a "high-resolution" table (sampled every
> 0.005 A^2) that extends to about 6A and is used to compute interactions
> when two central atoms are within about 4A of one another, and a
> "low-resolution" (sampled every 0.05 A^2) table that is used to compute
> longer-range interactions. (In this way, I can better vectorize the
> innermost loop--computing interactions between all atoms of water A and
> water B.) For now, I'm doing linear interpolation using double precision
> in the lookup table, but this is of course rather mismatched. A quick
> adjustment suggests that the lookup tables could be modified to encode
> cubic splines with an appropriate adjustment to the resolution, at a 10%
> cost in the overall performance. NAMD uses lookup tables with spline
> interpolation an even lower resolution of ~0.06A^2; it merely fails to
> treat the ubiquitous water in a special manner.
> I've profiled the code somewhat, but again I don't have many
> optimizations other than a well-planned indexing system for the residues
> and a nice set of lookup tables. The speed of the program seems to be
> quite insensitive to the size of lookup table, even on a four-year old
> processor with only 512kB L2 cache. Whether I double the resolution or
> cut it in half, the cpu time changes ~1%. The (linear interpolant) lookup
> tables for all atom types combined require ~200kB of memory, but I think I
> save more time and memory by simply foregoing the water:water neighbor
> lists.
> Perhaps this simple method could be implemented in the next PMEMD?
>
> Dave
>
Received on Thu Dec 14 2006 - 05:00:04 PST
