Dear Ralf,

I like your hybrid_ 36 scheme and will implement it and the two character 
chain IDs PDB file columns 21 and 22, right justified) when I next update 
SHELXL. Of course I will need to do some programming because of the SHELX 
'zero dependency' philosophy, but it seems to me to be straightforward. In 
fact SHELXL treats the residue numbers internally as strings anyway. Since 
I am not in the habit of releasing new versions in a hurry, that will give 
time to make the necessary changes to Coot and MMDB. The great advantage 
of these changes is that for the large majority of PDB files, nothing will 
change.

Although PDB files will be with us for many years to come, there is the 
separate problem of depositing reflection data, for which MMCIF formats on 
the lines indicated by Kim would be a good solution. At the moment people 
who have refined a non-merohedrally twinned structure with SHELXL deposit 
the .fcf file (CIF, not MMCIF!). The data in this file have been 
'detwinned' with the help of the refined structure and so the file can be 
read directly into Coot or used to calculate structure factors as if the 
crystal had not been twinned. Although this will still be needed, we 
should also be depositing the data as measured, so that the twinned 
refinement can be repeated or verified with another program. A similar 
situation arises with time-of-flight neutron diffraction data, e.g. from 
one of the new spallation sources. Incidentally the small molecule CIF 
format also has no answer yet to this problem, maybe the same solution 
could be found for both MMCIF and CIF?!

Best wishes, George

Prof. George M. Sheldrick FRS
Dept. Structural Chemistry, 
University of Goettingen,
Tammannstr. 4,
D37077 Goettingen, Germany
Tel. +49-551-39-3021 or -3068
Fax. +49-551-39-2582


On Wed, 8 Aug 2007, Ralf W. Grosse-Kunstleve wrote:

> Hi George,

> It seems to me that column 21 of an ATOM or HETATM instruction
> is always blank, and column 22 is the chain ID. So if we put a
> two-character chain ID right justified in columns 21 and 22, for the
> vast majority of structures there would be no change, and it would
> be relatively easy to change MMDB, Coot etc.  to accomodate the
> increase in the possible number of chains from 26 to (say) 36^2 =
> 1296 (if digits are allowed too).

I really like this idea and I will make phenix/cctbx work this way.

> The next problem is of course the 5-digit atom serial number in columns
> 7 to 11, which limits the total number of atoms in the structure to a
> paltry 99999. Many programs ignore this number, but it is used by the
> CONECT, SSBOND and CISPEP records in the PDB. However column 12 also
> appears to be blank, I think that using it (e.g. with A for atoms
> 100000 to 199999, B for atoms 200000 to 299999 etc.) would enable the
> sequence numbers to be recycled and would again require no change for
> the vast majority of PDB files. I personally think that this is a much
> better solution than what the PDB currently does for more than 99999
> atoms (they spread the structure over several PDB files with different
> PDB-IDs!).

The solution to this problem is to simply treat the serial numbers and
residue numbers as strings. X-PLOR/CNS has been doing this forever,
maybe other programs, too.
Implementations to generate intuitive, maximally backward compatible
numbers can be found here:

  http://cci.lbl.gov/hybrid_36/

This includes a Fortran-77 implementation without any external
dependencies, heavily tested with a large variety of compilers.

I think these simple tricks will be sufficient until we are all
retired!

Cheers,
        Ralf




       
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469