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

From: Thomas Evangelidis <tevang3.gmail.com>
Date: Thu, 18 Sep 2014 12:39:05 +0300

On 17 September 2014 18:42, Jason Swails <jason.swails.gmail.com> wrote:

> 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).
>
>
>
Yes, radiopt=0 suppresses all these errors.

I have two more queries. Since my protein is transmembrane, I defined the
receptor to include both the protein and the membrane. However, the
membrane spans the central box only. Does MMPBSA.py take into account the
periodic membrane bilayers at the x-y plane as well? I get "UserWarning:
Solvated topology 0 has IFBOX == 0" because I stripped the water when I
concatenated all individual trajectories. Does this prevent MMPBSA.py from
accounting PBC?

And the second query has to do with mpi. I don't have the AMBER14 source
yet, so I cannot compile AMBER-MPI version (AMBER12 fails to compile with
AmberTools14). So, although serial execution of MMPBSA.py runs smoothly,
when I invoke it with mpirun it runs multiple times the same calculation.
Does this have to do with compilation of AMBER14 source?

thanks,
Thomas




-- 
======================================================================
Thomas Evangelidis
PhD student
University of Athens
Faculty of Pharmacy
Department of Pharmaceutical Chemistry
Panepistimioupoli-Zografou
157 71 Athens
GREECE
email: tevang.pharm.uoa.gr
          tevang3.gmail.com
website: https://sites.google.com/site/thomasevangelidishomepage/
===============================================================
*Physics is the only real science. The rest are just stamp collecting.*
*- Ernest Rutherford*
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Sep 18 2014 - 03:00:03 PDT
Custom Search