AMBER Archive (2008)

Subject: Re: AMBER: Ewald troubles when running very big boxes

From: Robert Duke (rduke_at_email.unc.edu)
Date: Mon Nov 24 2008 - 20:09:23 CST

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_at_rci.rutgers.edu>
To: <amber_at_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_at_scripps.edu
> To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
> to majordomo_at_scripps.edu
>

-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber_at_scripps.edu
To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
      to majordomo_at_scripps.edu