Re: [AMBER-Developers] fftw questions

From: Jason Swails <>
Date: Sun, 12 Feb 2012 11:26:20 -0500

On Sat, Feb 11, 2012 at 10:40 PM, case <> wrote:

> Some questions about fftw:
> 1. Do we still need fftw2? The configure2 script configures it if both
> rims and mdgx are set to "no", but I don't understand why. What codes are
> using fftw2?

The PBSA codes were, but recent commit logs suggest a switch to fftw3 (I'm
also not sure if they're releasing their FFT-based PBC solver...) Once
PBSA no longer depends on it, it can just go away.

Note that there is buglet in the Makefile: the clean and uninstall targets
> try to run "make" inside fftw-2.1.5, but if those are not configured, then
> there is no Makefile to be run inside those directories.

But all of these clean rules are done with failures ignored, right? We do
the same thing, if memory serves, to conditionally build AmberTools and
Amber at the same time (Amber is built with "-(cd src && $(MAKE) install)",
in which no Makefile will be present for just AmberTools.

4. Do we really need the -nomdgx or -nocpptraj flags? I'd be inclined to
> have fewer flags, and ask users to just comment out the relevant lines in
> the
> Makefile if they happen on a machine where these programs fail to compile.
> Probably the same answer for -nomtkpp. I'm inclined to keep
> -noX11, since that is a relatively common option.

I say we can get rid of -nocpptraj and -nomdgx. Especially since cpptraj
is now a dependency of, it doesn't make sense to optionally _not_
install it and install MMPBSA at the same time (I didn't even know this was
an option). It's also not a heavy install -- it's relatively quick and
clean code that works on all compilers, AFAIK.

Same with mdgx -- since it compiles fine on all of our compilers, and it's
small enough not to make a significant impact on compile time. -nomtkpp,
on the other hand, I think should stick around. Last time I tried, MTK++
did not compile with PGI. It's also a fairly time-consuming install for a
program, and I can see instances in which people may not want to bother
installing it (especially if they know they won't need it).

On a related note, I also support getting rid of the -norism flag, and just
make _not_ building RISM the default for systems and compilers that don't
support FFTW3 (rather than configuring, hitting the case where RISM doesn't
work, and quitting with the instructions to use -norism the next time
around). Same thing with mdgx, really, since they both share that same

All the best,

Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
AMBER-Developers mailing list
Received on Sun Feb 12 2012 - 08:30:02 PST
Custom Search