Hi Jason,
Thanks much for the clarification. I guess the benefit in keeping fftw is
that it is a more full-fledged fft implementation, so for things other than
pmemd, amber may find use for some of the additional functionality at some
point. I certainly understand your concern about build complexity and
headaches though; for pmemd it was always easy IF the supercomputer center
being targetted already had fftw built; otherwise, I was at a minimum always
wondering if I was really getting the fastest version possible built. And
of course there is the complexity of parallel make, which I did not deal
with when I was most actively working on pmemd. I guess I would recommend
that you just leave the capability in place, and we change the documentation
to indicate the build problems, and suggest that for pmemd, building with
fftw is probably not worth the effort. The code impact in pmemd of
supporting fftw is absolutely minimal due to how I built the fft interface -
basically just a small set of call interfaces, if memory serves. Could be
there is a later, better version of fftw also - I have not recently looked
to see if fftw is still under active development.
Best Regards - Bob Duke
----- Original Message -----
From: "Jason Swails" <jason.swails.gmail.com>
To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
Sent: Tuesday, June 14, 2011 12:11 AM
Subject: Re: [AMBER-Developers]
[jason.swails.gmail.com:redundantredundancies]
> Hi Bob,
>
> I was certainly not clear enough about what I was suggesting. The fftws
> are, in my experience kind of a pain to build. First off, a parallel
> build
> *always* fails in fftw (make -j 2 install will choke on fftw for no reason
> other than perhaps the other threads are given a non-zero exit code).
> Also,
> an improperly timed "make clean" can trigger a fresh configure in those
> directories (because config.log or config.status may not exist, I forget
> which), and a bunch of tracked files are routinely changed by everyday
> commands (but not crucial ones, I don't think).
>
> I realize that pmemd's FFT is pretty fast, so my actual argument was that
> neither of the fftws are necessary at all, and their headache can be
> eliminated. Getting rid of them, though, would require RISM and mdgx to
> rewrite their FFT codes in order to use your interface, and as I'm not
> involved in their development, I can't speak to the cost-benefit ratio of
> keeping vs. discarding their respective fftws.
>
> Just thought I'd clarify.
>
> All the best,
> Jason
>
> On Tue, Jun 14, 2011 at 12:51 AM, Robert Duke <rduke.email.unc.edu> wrote:
>
>> Hi Jason,
>> On fft's in pmemd, my adapted version is pretty darn fast and portable
>> (original source was netlib, first adopted by Darden, and then I did a
>> substantial rewrite that made it faster), and you don't have to use any
>> external libraries. I don't think you were suggesting discarding it, but
>> I
>> wanted to be sure it is understood that it really does a pretty good job.
>> For the fftw stuff, it CAN be a bit faster on some machines, especially
>> at
>> very low processor count, but is a bigger pain to build, and as you scale
>> up
>> in processor count, it does not make much difference. There are two
>> versions because there were two extant versions of fftw at the time of
>> development, incompatible with each other, and everyone had not moved
>> forward to the second version. I suppose one could get rid of the older
>> version, but it is not as if there is a huge benefit in doing this. In
>> pmemd, the interface to the fft's has been generalized, making it easy to
>> add new fft implementations; this also means that there is little cost in
>> having a few extra implementations lying about.
>> Regards - Bob Duke
>>
>> ----- Original Message -----
>> From: "Jason Swails" <jason.swails.gmail.com>
>> To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
>> Sent: Monday, June 13, 2011 10:05 PM
>> Subject: Re: [AMBER-Developers] [jason.swails.gmail.com:
>> redundantredundancies]
>>
>>
>> > Hello everyone,
>> >
>> > The descriptions for each program are done (but only for AmberTools
>> > 1.5,
>> > none introduced since then). It is now Chapter 2 of the AmberTools
>> > manual,
>> > and is part of the master branch. Please feel free to improve the
>> > (short!)
>> > description for your program(s).
>> >
>> > tleap/sleap, cpptraj/ptraj, and MMPBSA.py/mm_pbsa.pl are obviously 3 of
>> > the
>> > big ones.
>> >
>> > For cpptraj/ptraj, I think cpptraj offers something new over ptraj that
>> > makes it worth keeping, but ptraj does too much to discard at this
>> > point.
>> > I
>> > support keeping both here.
>> >
>> > For tleap vs. sleap; I'm not quite sure what the design goal for sleap
>> was
>> > in the first place (as I wasn't around when it was begun), but it
>> > appears
>> > to
>> > be a bit buggy, and with no GUI version available, people will probably
>> > continue to use tleap/xleap. I don't think we can get rid of tleap (at
>> > least not at this point).
>> >
>> > For MMPBSA.py/mm_pbsa.pl, I'll obviously support our version, and it
>> does
>> > everything the perl version does as well as MM/3D-RISM and QM/MMGBSA if
>> > one
>> > isn't built.
>> >
>> > Onto some of the smaller ones, here are the redundancies I found:
>> >
>> > extractFrcmod.py / top2ff : extractFrcmod.py produces a complete frcmod
>> > along with LJ non-bonded terms.
>> > ambpdb / top2mol2 : ambpdb does what top2mol2 does as well as prints
>> > out
>> > other formats (PDB, PQR)
>> > reduce / protonator : based on descriptions I found, reduce does what
>> > protonator does and more
>> > mmE / NAB, sander, pmemd, mdgx : I'm not quite sure what sets mmE
>> > apart,
>> > although it may just be an example program using MTK++
>> > sequenceAligner/superimposer : It seems that superimposer just does
>> > part
>> > of
>> > what sequenceAligner does? Perhaps Martin can clarify here a little?
>> >
>> > Some more redundancies: we have Bob's pubfft (?) used in pmemd, as well
>> as
>> > 2
>> > versions of fftw (2.1.5 and 3.2.2).
>> >
>> > All the best,
>> > Jason
>> >
>> > On Mon, Jun 13, 2011 at 8:16 PM, case <case.biomaps.rutgers.edu> wrote:
>> >
>> >> I agree with Jason's comments below. I'm happy to let him get started
>> as
>> >> proposed, but I hope everyone will help out in working on
>> simplification.
>> >> There are both types of issues outlined below, plus much bigger
>> >> issues,
>> >> e.g.:
>> >>
>> >> tleap vs sleap
>> >> ptraj vs cpptraj
>> >> python vs perl versions of mm-pbsa
>> >>
>> >> I don't have any magic answers, but cleanup and simplification of both
>> >> code
>> >> and documentation should be a high priority for the next release.
>> >>
>> >> [On Jason's specific points, we can probably retire top2mol2, top2ff,
>> >> and maybe some of the other minor antechamber scripts.]
>> >>
>> >> ...dac
>> >>
>> >> ----- Forwarded message from Jason Swails <jason.swails.gmail.com>
>> -----
>> >>
>> >> Date: Mon, 13 Jun 2011 14:53:59 -0600
>> >> Subject: redundant redundancies
>> >> From: Jason Swails <jason.swails.gmail.com>
>> >>
>> >> I'm going through Amber and AmberTools right now and adding a section
>> >> of
>> >> the
>> >> manual that more or less lists all of the programs that exist in each
>> >> package right now that gives a short (1-sentence) description of its
>> >> functionality and where in the manual you should look for its
>> >> description.
>> >> In doing so, though, I've found numerous redundancies. For instance:
>> >>
>> >> extractFrcmod.py and top2ff do the same thing (although the first one
>> >> provides a more complete FF file from a given prmtop). top2mol2
>> >> mimics
>> >> ambpdb with the -mol2 flag. I can provide a more complete list after
>> I'm
>> >> done, though I think we should start thinning out the number of
>> >> provided
>> >> programs; at the very least eliminating redundancies. There are 97
>> >> (!)
>> >> programs installed with AmberTools (just serial).
>> >>
>> >> Thanks!
>> >> Jason
>> >>
>> >> ----- End forwarded message -----
>> >>
>> >> _______________________________________________
>> >> AMBER-Developers mailing list
>> >> AMBER-Developers.ambermd.org
>> >> http://lists.ambermd.org/mailman/listinfo/amber-developers
>> >>
>> >
>> >
>> >
>> > --
>> > 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
>>
>
>
>
> --
> 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 Tue Jun 14 2011 - 10:00:04 PDT
