I think the unit cell size (box x, y, or z length) and fft dimension maxima 
were set 1) assuming a more-or-less cubic unit cell, and 2) with the 
anticipation that using over 1 GB for data structures might get you into 
trouble (Darden set these values, not me, but I would guess that is what he 
was thinking about).  In the case of the fft limits, a 512 * 512 * 512 3d 
fft eats up around 1 GB I think, assuming 8 bytes per grid point (using a 
complex to real optimization in the fft's) (this is off the top of my head, 
so apologies if I don't have it exactly correct).  Under mpi, the grid will 
divide down by processor count, but basically you can get into trouble 
pretty quick with really huge fft grids.  I do think your box ratio is a bit 
scary in that you are going to have very directional periodicity artifacts, 
but if your water buffer is big enough, I guess things should be okay. 
There may be some subtle issues with constant pressure perhaps.  This thing 
may parallelize a bit strangely due to the huge difference in fft grid 
points in the x, y, z.  I would definitely use pmemd (after hacking it's 
parameter limits in mdin_ewald_dat.fpp) because it will reorient the box for 
you, allowing for optimal parallelization of the fft's (not in 
minimizations, but in non-respa md).
Regards - Bob Duke
----- Original Message ----- 
From: <steinbrt.rci.rutgers.edu>
To: <amber.scripps.edu>
Sent: Monday, November 24, 2008 3:50 PM
Subject: AMBER: Ewald troubles when running very big boxes
> Hi Amber community,
>
> in trying to simulate a rather large and elongated system (50x50x1000 A) I
> ran into the following problems when executing sander:
>
> First:
>
> nfft1-3 too large! check on MAXNFFT in ew_bspline.f
>
> and second:
>
> Ewald PARAMETER RANGE CHECKING:
> parameter c: (unit cell size)  has value  0.10224E+04
> This is outside the legal range
> Lower limit:  0.10000E+01 Upper limit:  0.10000E+04
> Check ew_legal.h
>
> both are connected to the unusually long and big box. When I made the
> changes suggested (increasing maxnfft to 1200 and boxhi to 2000) and
> recompiled, my calculations appear to run fine.
>
> My question is, has anyone experimented with this before and wants to warn
> me about problems that might occur? Specifically, are the various Ewald
> maximum size parameters there for a reason or leftovers from a time when
> array sizes where just set to a value that seemed large enough?
>
> Thanks in advance,
>
> Kind Regards,
>
> Thomas
>
> Dr. Thomas Steinbrecher
> BioMaps Institute
> Rutgers University
> 610 Taylor Rd.
> Piscataway, NJ 08854
> -----------------------------------------------------------------------
> 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 Fri Dec 05 2008 - 16:38:26 PST