Re: [AMBER] MMPBSA.py: PrmtopError: Residue mismatch while mapping. Incompatible topology files or bad mask definitions

From: Jason Swails <jason.swails.gmail.com>
Date: Wed, 17 Sep 2014 11:42:17 -0400

On Wed, Sep 17, 2014 at 11:33 AM, Thomas Evangelidis <tevang3.gmail.com>
wrote:

> On 16 September 2014 19:13, Jason Swails <jason.swails.gmail.com> wrote:
>
> > On Tue, 2014-09-16 at 17:05 +0300, Thomas Evangelidis wrote:
> > > Greetings,
> > >
> > > I want to run MMPBSA.py script using 3 different trajectories (complex,
> > > receptor, ligand). The difference between the receptor and the complex
> > > trajectories was that the receptor had an aspartate protonated which
> was
> > > unprotonated in the complex. This is perfectly fine in reality, but
> when
> > it
> > > attempted to use MMPBSA.py the program complained.
> >
> > This is actually not fine (at least not according to the details you've
> > written here). The MM/PBSA thermodynamic cycle does not accommodate
> > "chemical" changes (i.e., changes in covalent bonds). There is an extra
> > process of deprotonation and proton desolvation that is not accounted
> > for. So you would need to add on a thermodynamic cycle similar to the
> > kind used for pKa calculations and constant pH simulations.
> >
> > > So I modified the
> > > receptor trajectory and topology by removing the extra proton from the
> > ASP
> > > side-chain. However, I still get a residue mismatch error that may be
> > cause
> > > by the modification I introduced. Do you believe this is the case? If
> > yes,
> > > is there any work around to fix it?
> >
> > MMPBSA.py takes steps to catch errors that break the assumptions of
> > MM/PBSA analyses (like what you are doing here). [1] Simply stripping
> > the extra proton will not work -- MMPBSA.py also checks that the residue
> > sequences are the same in the bound and unbound states (ASH != ASP) and
> > it checks that the atoms have the same charges in the bound and unbound
> > states... which they won't if all you did was strip out a hydrogen atom
> > using cpptraj.
> >
> > You can use MMPBSA.py to process each trajectory independently and then
> > combine them yourself as legs of the applicable thermodynamic cycle for
> > your process.
> >
> >
> >
> Good point. The protein is a transporter with a binding pocket that becomes
> solvent exposed (outward facing conformation) when ASP51 is protonated
> (ASH51). So the receptor trajectory was actually created to monitor the
> opening of the substrate binding cavity. Deprotonation of ASH51 occurs upon
> ligand binding and triggers the occluded ==> inward facing transition. My
> purpose is to compare free energies of binding for a series of analogues
> with know kinetics. This protonation-deptonation is associated with large
> conformational changes and hence a significant entropic change which is
> impossible to estimate. So I thing my best bet is to calculate relative
> free energies between the ligands (given that the entropic cost of binding
> is quite similar for each of them) by using only the complex trajectories I
> have.
>

​Sounds reasonable.

I tried to do that for one complex but I am getting a series of errors of
> the following type:
>
> PB Bomb in pb_aaradi(): No radius assigned for atom 65 CB 3C
> PB Bomb in pb_aaradi(): No radius assigned for atom 79 CB 2C
> PB Bomb in pb_aaradi(): No radius assigned for atom 115 CG CO
>
> These are associated with protein atoms, which is strange since I used
> ff14sb. I tried to correct them with parmed.py using:
>
> change AMBER_ATOM_TYPE .%CB C
> change AMBER_ATOM_TYPE @%CG C
>

​It looks to me like you are substituting atom names for types. I think
this should read

change AMBER_ATOM_TYPE @%3C CT
change AMBER_ATOM_TYPE .%2C CT
change AMBER_ATOM_TYPE @%CO CT


> Is this correct? Should all these carbons be of type 'C' ?
> ​
>

​I would use type CT (used to be the prototypical sp3-hybridized C used for
all Calpha's in ff99SB and earlier). C is the carbonyl type, I believe.
 Of course it may be safer to check the parameter files and see what the
3C, 2C, and CO types really are and pick the closest-matching type from
ff99SB. Although I think you can specify radiopt=0 to use the radii in the
prmtop file instead? (it doesn't appear that PBSA has updated its atom type
lists to support the new types in ff14SB).

Hope this helps,
Jason

-- 
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Sep 17 2014 - 09:00:03 PDT
Custom Search