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
Received on Fri Feb 01 2013 - 13:30:03 PST
