why does Coot ignore these atoms renumbered back to 1 beyond 10000?
Shouldn't it just ignore the irrelevant atom number?
Phil
On 3 Jun 2009, at 09:19, Kevin Cowtan wrote:
Hi!
Hybrid-36 (initial idea from Ralph Grosse Kunstleve, I think) works
around this problem by allowing higher numbered atoms to be numbered
in base 36 starting from A0000. CCP4 v6.1.1 and recent versions of
Coot support this, as does phenix.refine.
http://cci.lbl.gov/hybrid_36/
However, last time I checked, it wasn't available in refmac. I think
refmac ignores atom numbers on read, and writes out its own atom
numbers sequentially, looping at 100000. As a result, you cannot
read a refmac output PDB file with more 100000 atoms into Coot or
any other CCP4 application without somehow renumbering the atoms
first.
Garib: Have I got that right? Is that still the case in recent
versions?
Kevin
Edward Miller wrote:
Hey Paul,
I believe I have figured out the problem - but not the solution.
On closer inspection, it wasn't just the numerically labelled
chain IDs that weren't read, a few of the alphabetical chains were
also not read.
What happens is REFMAC restarts atom numbering once 100000 atoms
are reached when outputting the refined coordinates.
COOT was reading in the first 99999 atoms, numbered 1-99999 by
REFMAC, then the second 99999 atoms, again numbered 1-99999 by
REFMAC. At this point, however, REFMAC for some reason made the
next atom 100000 and then restarted numbering at 1. This atom,
numbered 100000, was not read by COOT and nor where any subsequent
atoms.
The input coordinates that I used for REFMAC, which again consisted
of 60 chains, was created by combining sets of 10mers, thus the
atom numbering restarted after each 10 chains. REFMAC had no
problem refining these coordinates and COOT had no problem reading
these coordinates.
To further confirm that COOT is failing once it reads atom 100000,
I wrote a little perl script to properly renumber the atoms in the
REFMAC refined coordinates. In this file, there are correctly
246960 atoms.
Within my perl script, I formatted the output such that the atom
numbers eat into the spaces after "ATOM" like so:
ATOM 246960 O LEU 7 736 64.294 96.393-111.576 1.00 34.97
I see now that the last atom COOT reads in is atom number 99999.
Perhaps, I fear, this is a problem with the PDB format - that the
column width for atom numbers can not accommodate more than 99999
atoms.
Ed
On Tue, Jun 2, 2009 at 9:39 AM, Paul Emsley <paul.ems...@bioch.ox.ac.uk
<mailto:paul.ems...@bioch.ox.ac.uk>> wrote:
Edward Miller wrote:
Hey Folks,
I'm working on refining a full capsid containing 60 chains.
Using the chain ID column, I've numbered my chains A-Z, a-z,
and
0-7. I was successfully able to refine my capsid in refmac
using
this chain ID naming scheme.
However, coot fails to read in any of the chains labeled 0-7.
I don't know why this is failing - I will try to make a synthetic
PDB file with 60 chains to see if I can reproduce this.
Relatively recently Eugene has extended mmdb to work with the
hybrid_36 format. So for now you could go that route.
Paul.
