Re: AMBER: PMEMD and sander.MPI

From: Robert Duke <rduke.email.unc.edu>
Date: Tue, 9 Sep 2008 10:14:52 -0400

PMEMD uses a slightly different algorithm than sander to calculate the nfft1,nfft2,nfft3 parameters if you do not provide them. If I remember correctly, I looked at the sander algorithm at some point and determined that it would not always provide a grid density of >= 1 grid/angstrom; I was also adapting the pmemd code to support different grid prime factors for fftw at the time (fftw can use 7 as a prime factor without a substantial performance penalty; this can result in a better grid fit, and use of this fft prime factor is not available in sander). So pmemd in general will opt for the same or a slightly tighter grid as sander when you use the "public" fft's. If you use fftw, then a prime factor of 7 is available, and you may actually use a lower grid density because you can still get a grid density of >= 1 grid/angstrom - this is exactly what you see here for your example. If you recompiled pmemd to use the public fft's, there is a pretty good chance you would use the same grid density as sander (not saying you have to do this; I am just pointing out that you are getting the grid choices you have here due to fftw). Also note that if you use fftw, there may be slightly higher variation in fft results due to the fact that fftw will at the beginning of a run choose between several different algorithmic alternatives based on their performance on your specific machine; generally the alternatives are sufficiently close that on some machines you get different algorithms chosen in different runs. Now is this less accurate? No, presumably the fftw algorithmic alternatives are all pretty close in terms of the accuracy they deliver. But there is a difference in repeatability. As I say, these are not pmemd issues, these are fftw issues. Now, is pmemd faster because it is less accurate? NO. An effort has been made to pretty much get pmemd to reproduce sander calcs to the limits of precision on the given architecture (ie., rounding error). It is faster because a huge amount of work has been spent on designing and developing better algorithms that enhance both single processor and multiprocessor performance. One of the really annoying things about MD is that very slight differences in rounding error very quickly grow into very noticeable differences in results. One has to keep in mind that the differences observed are generally not significant.

Regards - Bob Duke
  ----- Original Message -----
  From: Germain Vallverdu
  To: amber.scripps.edu
  Sent: Tuesday, September 09, 2008 9:50 AM
  Subject: AMBER: PMEMD and sander.MPI


  Hello AMBER !

  I am trying to do NPT simulations with PMEMD. Then I ran two identical simulations, one with sander.MPI and one with PMEMD to see differences beetwen them.

  Firstly, I do not understand why ewald parameters are not the same :

  sander gives :

  NFFT1 = 60 NFFT2 = 72 NFFT3 = 72

  PMEMD gives :

  NFFT1 = 56 NFFT2 = 70 NFFT3 = 72

  The AMBER manual said that if one decrease NFFT1,2,3 this leads to faster calculations but less accurate. Nevertheless, are this differences relevant ? And why sander and PMEMD do not give the same size of the grid ?

  A more general question : is pmemd faster than sander.MPI thanks to algorithm or is pmemd less accurate than sander ?

  Thanks

  Germain
  --
  Germain Vallverdu
  Laboratoire de Chimie Physique
  Université Paris Sud 11
  germain.vallverdu.lcp.u-psud.fr
  01 69 15 30 38 / 06 88 59 08 87
  Chacun de nous a son étoile. Suivons la en nous félicitant de la voir chaque jour un peu plus loin ! (V. Grignard)
  ----------------------------------------------------------------------- The AMBER Mail Reflector To post, send mail to amber.scripps.edu To unsubscribe, send "unsubscribe amber" (in the *body* of the email) to majordomo.scripps.edu
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
      to majordomo.scripps.edu
Received on Wed Sep 10 2008 - 06:07:44 PDT
Custom Search