Yes, PBSA has switched from fftw2 to fftw3, and the changes have been pushed to remote master branch.
We have the FFT solver implemented in PBSA, but the default PBC solver is PCG.
Best,
Qin
On Feb 12, 2012, at 10:16 AM, Ray Luo wrote:
> Yes ... Wes and Qin just removed the fftw2 dependence. They haven't cleaned up the dependence I think ...
>
> Ray Luo, Ph.D.
>
> On Feb 12, 2012, at 8:26 AM, Jason Swails <jason.swails.gmail.com> wrote:
>
>> On Sat, Feb 11, 2012 at 10:40 PM, case <case.biomaps.rutgers.edu> 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 MMPBSA.py, 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
>> dependency.
>>
>> All the best,
>> Jason
>>
>> --
>> Jason M. Swails
>> Quantum Theory Project,
>> University of Florida
>> Ph.D. Candidate
>> 352-392-4032
>> _______________________________________________
>> AMBER-Developers mailing list
>> AMBER-Developers.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Feb 12 2012 - 15:30:02 PST
