On 14 Jun 2011, at 15:07, Jason Swails wrote:
> 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?
>
superimposer is for small molecule superimposition while sequenceAligner aligns proteins.
HTH,
Martin.
> 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
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Jun 14 2011 - 07:30:06 PDT
