Re: [AMBER] Problem using solvatebox for large, linear peptide

From: Ismail, Mohd F. <farid.ou.edu>
Date: Fri, 1 Feb 2013 23:34:54 +0000

saveamberparm "unitname" foo.prmtop foo.inpcrd

*******************************
Mohd Farid Ismail
Graduate Student
Dept. of Chemistry/Biochemistry
University of Oklahoma
Norman 73019

________________________________________
From: Joe Passman [joepassman.comcast.net]
Sent: Friday, February 01, 2013 5:32 PM
To: AMBER Mailing List
Subject: Re: [AMBER] Problem using solvatebox for large, linear peptide

Thanks for the information. I am need of solvating the entire protein. I would like a big enough buffer region to prevent interactions among replicas. What do you suggest for an appropriated buffer size? The radius of gyration for my system is about 21 ang. I would like to be able to vizualize the information in vmd, so a fix before the move to mmCIF would be awesome .


This might be a dumb question... Is the structural information saved using the command 'saveAmberparm <foo.prmtop> <foo.prmcrd>'? I am having some error when running these through ambpdb. When I run 'ambpdb -p foo.prmtop <foo.prmcrd> visual.pdb', The error reads


'ATOMS DO NO MATCH BETWEEN PARM AND MIN FILES 1205568 120556'.


Is there another way to do this?


Thanks! Joe Passman
----- Original Message -----
From: "David A Case" <case.biomaps.rutgers.edu>
To: "AMBER Mailing List" <amber.ambermd.org>
Sent: Friday, February 1, 2013 2:14:27 PM
Subject: Re: [AMBER] Problem using solvatebox for large, linear peptide

On Fri, Feb 01, 2013, Jason Swails wrote:

> Also, I suspect that what you may be seeing with the large box size is as
> much a limitation of the PDB file as it is a tleap bug -- the format
> requirements of the PDB file is very strict, and if any of the numbers are
> too large, you can get strange behavior with different parsers.

As per usual, Jason is much smarter that I am. Indeed, the problem is
not with how tleap solvates systems, but in how it writes pdb files with
residue numbers greater than 9999, since the official pdb standard only
allocates 4 columns for residue numbers.

When tleap encounters a residue number greater than 9999, in writing the pdb
file using savePdb, it appropriates column 27 of the pdb file, and starts
writing 5 digit residue numbers in columns 23-27. VMD (and maybe other
viewers) not surprisingly are not expecting this, and the display "looks"
wrong.

If you save the prmtop and coordinate files in tleap, then use ambpdb to
create the prmtop file, ambpdb starts residue numbers over again from zero
when the residue number gets to be greater than 9999. VMD seems happy with
this decision, and the file looks fine visually.

[The current "official" solution from the pdb is to split such systems into
several files (see, e.g. files for the ribosome). The upcoming "official"
solution is to use the mmCIF format, which (for what is relevant here) uses
white space to delimit the various parts of an atom record, and hence has no
inherent limit on the number of residues.]

We can easily fix tleap to do what ambpdb does for residue numbers greater
than 9999 (and atom numbers greater than 99999), which is arguably a better
workaround until we all move to mmCIF.

...dac

p.s.: you still don't need a 60 Ang buffer for your system, in my view.

_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber

_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Feb 01 2013 - 16:00:03 PST
Custom Search