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.
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.
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.
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?
...thanks!....dac
Received on Wed Apr 18 2007 - 06:07:22 PDT
