Re: amber-developers: experience with sleap

From: Wei Zhang <>
Date: Tue, 17 Apr 2007 11:28:23 -0500

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.
Yes, this can be fixed very easily.

>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.
It won't be hard to impose such a standard order, I think I can do it
very easily.

>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
>quine% sleap <
>[gtkleap]$ using file /home/case/amber10/dat/leap/cmd/leaprc.ff99SB
>[gtkleap]$ [gtkleap]$ using file
>[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]$
>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.
There is such a option to echo input command in sleap, by default it is
turned off, you can turn it on by typing:

     set default echo on

>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.
I can make sleap to accept "-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
Yes, mostly likely it is because of the improper dihedral. Can you also send
me a copy of you pdb file?

>Also, NEXT, NUMBND, NUMANG and NATYP are different in the sleap prmtop than
>in the tleap prmtop: are these expected differences?
I will look into this right now, should be easy to fix it.

Received on Wed Apr 18 2007 - 06:07:35 PDT
Custom Search