David A. Case wrote:
>Here are some initial comments about my experience with sleap.
>
>I first tried to load a simple pdb file (prepared by reduce) for ubiquitin.
>This was just loadPdb followed by saveAmberParm
>
>1. The sleap coordinate file has 8 blank spaces at the end of every
>coordinate line, whereas tleap does not. (That is, the sleap lines are 80
>characters long, but the tleap lines are 72 characters long). This diff
>with established behavior should be easy to fix.
>
>
Fixed
>2. The order of atoms within a residue follows the Amber library for tleap,
>but for sleap, the order of atoms is different. I don't know how hard this
>is to "fix", or even if it should be fixed. sleap appears to follow whatever
>order is in the input pdb file. And, if hydrogens are missing (and are added
>by sleap) then they go at the end of the residue.
>
>I'm inclined to think that this is going to cause lots of problems. The
>fact that the order of atoms depends so strongly on what is in the input pdb
>file means that re-making a prmtop file later (say to change some initial
>coordinate, or whatever) could change the prmtop file in mysterious ways.
>Anything that depended upon atom number (e.g. nmr restraints) would have to
>be re-done, and errors could easily creep in. Plus, there may be utilities
>out there than depend upon a "standard" atom order.
>
>I don't know how hard it would be to impose a standard order on the atoms
>within a residue, however.
>
>
Fixed, see test case pdbent/Run.pdbent2 for example
>3. sleap doesn't give any real feedback to the user: it says what files
>are being read in, but after that, there is no echoing of commands: here is a
>sample:
>
>quine% sleap < leap.in
>[gtkleap]$ using file /home/case/amber10/dat/leap/cmd/leaprc.ff99SB
>[gtkleap]$ [gtkleap]$ using file
>/home/case/amber10/src/gleap/leapdat/parm99.dat
>[gtkleap]$ using file /home/case/amber10/dat/leap/parm/frcmod.ff99SB
>[gtkleap]$ using file /home/case/amber10/dat/leap/lib/all_nucleic94.lib
>[gtkleap]$ using file /home/case/amber10/dat/leap/lib/all_amino94.lib
>[gtkleap]$ using file /home/case/amber10/dat/leap/lib/all_aminoct94.lib
>[gtkleap]$ using file /home/case/amber10/dat/leap/lib/all_aminont94.lib
>[gtkleap]$ using file /home/case/amber10/dat/leap/lib/ions94.lib
>[gtkleap]$ using file /home/case/amber10/dat/leap/lib/solvents.lib
>[gtkleap]$ [gtkleap]$ [gtkleap]$ [gtkleap]$ [gtkleap]$ [gtkleap]$ [gtkleap]$
>[gtquine%
>
>
>This is not all bad: tleap prints lots of useless and confusing information,
>but I think sleap goes too far in the other direction. How about at least
>echoing the input commands? And, there are lots of extra prompts at the end
>that should be removed.
>
>4. In tleap, you type "tleap -f filename" to read commands from a file.
>In sleap, you have to use redirection, I guess: "sleap < filename". Neither
>program accepts what the other one requires.
>
>
both fixed, sleap now takes "-f" option.
>5. The dihedral angle energy is different for tleap and sleap, even when
>all atoms are present in the input pdb file. My guess is that some improper
>dihedral term has a different order of atoms, but I'm not sure of that. I'll
>have to create a debug version to print out all the dihedrals to track this
>down.
>
>Also, NEXT, NUMBND, NUMANG and NATYP are different in the sleap prmtop than
>in the tleap prmtop: are these expected differences?
>
>
Havenot got chance to look at it, will do it tommorow.
Sincerely,
Wei
>
>...thanks!....dac
>
>
>
>
>
Received on Wed Apr 18 2007 - 06:07:40 PDT
