Hi Sam, The spillover into column 6 was intentional, but it is understandable that it could cause problems for other programs. The original PDB format (as you must be painfully aware) was not designed to handle such large structures as we have today, and different programs have taken different liberties with the format to try to accommodate these things. PDB itself has taken the approach of splitting large structures into multiple entries. Your approach breaks the rule of unique serial numbers, and Chimera's approach messes with column 6. Chimera can use the serial numbers as unique identifiers, and if I remember correctly, we started using column 6 after noting that another program (maybe it was AMBER trajectories?) expanded large serial numbers there. Conversely, the programs you are using apparently tolerate duplicate serial numbers but not numbers in column 6. I'm not sure what the upshot will be, but it is useful to know about these problems. Thanks for letting us know, Elaine ----- Elaine C. Meng, Ph.D. UCSF Computer Graphics Lab (Chimera team) and Babbitt Lab Department of Pharmaceutical Chemistry University of California, San Francisco On Feb 14, 2010, at 1:00 PM, Samuel Coulbourn Flores wrote:
Hi Guys, I thought I'd point out a problem with Chimera's atom numbering. I am working on a ribosome model which has about 50 chains. The ribosome pushes the limits of the PDB format; the five columns reserved for atom numbers are not sufficient to give each atom a unique atom number. This is not typically a problem for me, I just start the atom numbering at 1 for each chain. However chimera doesn't do this, it tries to assign sequential, unique numbers to each atom and ends up spilling over onto column 6, which is in the record name field. This wreaks havoc with other programs which I use to process the PDB files that chimera puts out. I am manually renumbering to deal with the issue, but the developers should think about a more permanent solution. Sam