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
Received on Tue Jun 14 2011 - 00:30:03 PDT
