On Tue, Jun 14, 2011 at 4:45 AM, Martin Peters <martin.b.peters.me.com>wrote:
> Hi,
>
> Regarding the MTK++ applications mentioned below: protonator, mmE,
> and SequenceAligner.
>
> Details and examples can be found in the MTK++ manual found in
> the $AMBERHOME/doc folder.
>
> The sequenceAligner programs gives the user the ability to superimpose
> two structures when the residue and/or the atom numbers are out of sync
> by doing a Needleman-Wunsch or Smith-Waterman sequence alignment
> followed by a superimposition. This is common when dealing with a family
>
I think my main question was what does superimposer do? And is its function
different (and inaccessible) through sequenceAligner?
Thanks!
Jason
of protein-ligand complexes and researcher would like to see the ligands
> superimposed using the backbones of the proteins.
>
> These programs could be turned off if it is deemed necessary to tidy up the
> bin directory.
>
> Regards,
>
> Martin.
>
>
> On 14 Jun 2011, at 08:11, Jason Swails wrote:
>
> > 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
>
--
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 - 07:30:05 PDT
