[Dock-fans] amber_score

Francesco Pietra chiendarret at yahoo.com
Fri Nov 2 03:28:16 PDT 2007

I am hurriedly replying the second time this message to inform that the
suggestion "take the pdb file from step 2g and use that for prepare_amber"
solved the problem, as reported below (while pdb from step 2f failed).

--- Scott Brozell <sbrozell at scripps.edu> wrote:

> Hi,
> I answered some of these in the latest 'Combining DOCK with AMBER'
> but reproduce them for simplicity.
> On Wed, 31 Oct 2007, Francesco Pietra wrote:
> > I open a new thread (amber_score) because previous thread (Combining Dock
> with
> > Amber) was becoming too complex, in the hope to get some general
> guidelines.
> > 
> > To summarize
> > 
> > (1) With a pore protein model and a flexible 150-atoms ligand (working with
> > Dock6.1 and Chimera 17 Oct build) I could carry out both rigid_docking and
> > flex_docking along the default lines of the tutorials. The ligand is seen
> > inside the pore, roughly the same view in both cases.
> Good.
> > (2) As prepared with Chimera, the protein did not allow to get (via
> dock-prep)
> > the prmtop and inpcrd files needed for amber_score. Therefore, I prepared
> the
> > protein with Leap in Amber9, getting prmtop and inpcrd, which allowed a
> correct
> > graphical representation in both Chimera and VMD.
> This is not surprising since Amber's LEaP (which is the vehicle for
> amberization under the hood of DOCK's prepare_amber.pl)
> is the sole mechanism for Amber input preparation.
> Here is the usual sequence:
> Do docking (along the lines of tutorials
> Structure Preparation,
> Sphere Generation and Selection,
> Grid Generation,
> Docking );
> Then rescore with Amber_score (along the lines of tutorial
> Structure Preparation & AMBER Score ).
> Note that Amber_score has receptor input files distinct
> from DOCKing receptor input files.
> Typically, one has an original pdb which is the starting point for
> dock prep, and the resulting mol2 file (from step 2f in the
> Structure Preparation tutorial) also can be saved as a pdb;
> it is this later pdb that is usually the starting point for
> prepare_amber.

That pdb resulted in the same failure to create prmtop and inpcrd files. The
log told that many standard residues did not have a valid name.

>  However, one can imagine several ways to
> obtain the actual receptor input files; for example, one might
> take the pdb file from step 2g and use that for prepare_amber.
> This would be a simple consistency test for protonation
> between the DOCKing receptor and the Amber_score receptor.

That proved to work with my protein. The noH.pdb from the suggested step 2g,
together with the same mol2 file for the ligand, allowed prepare_amber.pl to
produce valid prmtop and inpcrd files. (As all warning suggested, it was a
problem of protonation state. With Leap in Amber9 I did not succeed to get back
compatibility of files with Chimera; now amber_prepare.pl has done the Leap
work for me). So that, I have now hierarchical continuity in scoring and
rescoring. Actually, the rec.pdb version used in the scoring is not the best
version, still containing long bonds (I had not yet placed the TER records to
get rid of them). It still also contains a molecule of HOH inside the pore (in
the real world, the pore should contain much water and K+ ions that I
artificially remove for docking; one might try to leave also K+). At any event,
from now on it is to the operator to avoid mistakes.

> It seems to me that you are performing various consistency checks
> between DOCKing inputs and Amber_score inputs.
> That is a sound approach, but human inspection will play a
> dominant role since the DOCK and the Amber packages are
> not input compatible (despite the appearance through the
> magic of amberization).
> [Note to Amber/DOCK superexperts: there are several caveats
> that I have ignored for pedagogical purposes.]
> > (3) The pdb file for the protein created in Amber9 from prmtop and inpcrd
> with
> > ambpdb proved unsuitable for Chimera dock-prep (standard amino acids were
> > mis-viewed as non-standard residues and assigned to Antechamber, which
> wrongly
> > calculated fractional charge for the residues). I changed strategy, loading
> the
> > protein to Chimera from the Leap-created prmtop and inpcrd files. That also
> > failed (dock-prep), but for a different reason, Value Error: underlying C++
> > Molecule object is missing (I have documented that with an error.log on
> > previous thread), which I do not understand.
> Please post this small episode to Chimera-users.
> This may be an issue of operator error, but maybe not and
> anyways it may help them improve robustness.
> > Now the files from Leap (2 above) allowed amber_scoring. I carried out both
> a
> > rapid (few minutes) "ligand" option and a longer (4 hours) "everything"
> option.
> > In both cases, from the complex "final_pose.amber.pdb", the ligand is
> immersed
> > into the protein, though not along the pore walls, unlike with the rigid
> and
> > flex docking mentioned in (1). The bad point is that the ligand was broken
> into
> > two major fragments, and minor CH2 fragments. At a rough inspection, the
> > protein does not appear to have suffered any major damage, in both options.
> I
> > must add that breakage of the ligand is surprising because it is a
> thermally
> > very stable molecule.
> Something is amiss - covalent bonds should not break.
> Did you run prepare_amber.pl ?
> > I am much confused about the line to follow for amber_score. As carried out
> > above, the receptor has no spheres, while the ligand mol2 file was taken
> from
> > the tutorial-like procedures. Does the receptor pass through the stages of
> > spheres/grid also for amber_score?
> Amber_score only uses a sphere representation of the receptor
> for the distance-movable-region.  Otherwise Amber_score does not use
> any spheres, and it never uses any grids.
> Perhaps my comments to (2) are useful here ?
> Scott

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the Dock-fans mailing list