From P.J.Briggs@dl.ac.uk Wed Mar 15 15:12:30 2006 Date: Fri, 10 Mar 2006 20:00:38 +0000 From: P.J.Briggs To: Alexei Vagin Cc: Peter Briggs , Huanwang Yang Subject: Problems/fixes for SFCHECK with CIF coordinate input Hi Alexei Apologies in advance for this long email message. I'm at the PDB site at the RCSB in New Jersey and I have been talking to one of the programmers here (Huanwang Yang) about some difficulties he's experienced when using the cif coordinate input options of SFCHECK. For some of these we think that we have fixes and for some we don't, so we would be grateful if you would comment: 1. Recognising CIF files 1.1 In sfch_subr.f s/r CHECK_COORD_FILE, when testing if the input file is really CIF, there is an assumption in the code that the file will have an "_atom_site.*" token within the first 3000 lines of the file. However it is possible that this is not always the case. Increasing the limit to 5000 addresses this problem for files that we looked at. 1.2 SFCHECK will not read CIF coordinate files unless they have a ".crd" extension. We're not sure of your reason for this, and why ".cif" extensions should not be acceptable. The patch file cif-recognition.patch has changes to deal with these two issues. 2. Acquiring symmetry information 2.1 In sfch_subr.f s/r RD_TTL_CRD, if tokens matching "_symmetry.space_group_n*" appear more than once then only the last occurance is used to set the value of the variable CR_SPGR. In one example however the second occurance had the value "?" which overwrote the previous value of "P 21 3". So perhaps there should be a check that ignores values of "?". An alternative solution suggested by Huanwang is to look explicitly for the Hall symbol. The attached patch symmetry-problem.patch implements his suggestion. 3. CIF parsing There are a number of problems with the CIF parsing, at least for coordinate files. 3.1 In SFCHECK 6.0.5 there seems to be a limit on the length of lines and number of tokens read from each line in the CIF file, which means that values beyond these limits are lost. Within a loop this can mean that some data is lost, and that other data is misassigned within SFCHECK - obviously this causes severe problems. It looks like you have made a lot of changes to deal with this in 7.1.01 but I think you missed a few occurances - the patch file cif-parsing.patch has changes to correct a few more of these. 3.2 SFCHECK expects that there will not be additional CIF data items after the atom records, but I understand that this expectation is not part of the CIF standard so it is possible to have CIF files where this is not the case, and the program can't handle this. (I worked around this by removing the "trailing" CIF items and don't have a code fix.) 3.3 SFCHECK isn't able to handle some CIF tokens where single quote characters appear within a quoted string. In this case the program gets confused if a quoted token contains an additional quote, e.g. 3 non-polymer syn '3,5,3'TRIIODOTHYRONINE' 650.978 1 ? ? ? (_entity.pdbx_description token value taken from entry 1XZX). I understand that this is valid CIF. This doesn't cause the program to stop though, so is not a major problem. The main problem we had was trying to use SFCHECK 7.1.01 on data for the PDB entry 1XZX, but we had similar problems using SFCHECK 6.0.4 (from CCP4 release 5.0.2). It seems to work okay for PDB coordinates for the same entry. There are a couple of other minor things that are not really related to the above: 4. When using PDB data, the Rfactor reported by SFCHECK can sometimes be quite different from that reported in the file, although an independent run of REFMAC corroborates the reported number (again, observed for 1XZX). This was using SFCHECK 6.0.5, in case you want to compare. Huanwang notes that the results from version 6 using mmcif input are much better (i.e. closer to the reported values and the values from REFMAC) than those from v6 and v7 using PDB input. 5. It appears that SFCHECK doesn't know about atom type "AS", which I understand is quite common in the PDB archive. The patch as-name.patch adds it in. Also the residue MSE (i.e. Se attached to MET) also appears to be unrecognised by SFCHECK (I haven't tried to add this however). 6. Huanwang reports that when inputing CIF, SFCHECK uses its own numerical chain ID is numerical, instead of the chain ID found in the CIF file. The patch file group-id.patch tries to fix these. 7. It's not very clear which version of SFCHECK is available from your website (the documentation says that it's 7.0.4, but the source code says 7.1.01). 8. At the RCSB they are also interested in writing out to CIF some of the data (for example the density correlations for each residue) that is currently only output to the final postscript file. In order to do this Huanwang has extended the SFCHECK 6.0.5 code, and is now migrating the changes to 7.1.01, however he would be interested in having the changes incorporated into your version of SFCHECK in future if that is possible. Is this something that you would consider? Again apologies for the long email. I look forward to hearing from you about these problems, please let me know if you would like more information. I'm sure that I will see you in person in York at the end of the month. Best wishes Peter -- ___________________________________________________ Peter J Briggs, pjx@dl.ac.uk Tel: +44 1925 603826 CCP4, ccp4@dl.ac.uk Fax: +44 1925 603825 http://www.ccp4.ac.uk/ Daresbury Laboratory, Daresbury, Warrington WA4 4AD [ Part 2, "" Text/PLAIN (Name: "cif-recognition.patch") 28 lines. ] [ Unable to print this part. ] [ Part 3, "" Text/PLAIN (Name: "symmetry-problem.patch") 76 lines. ] [ Unable to print this part. ] [ Part 4, "" Text/PLAIN (Name: "cif-parsing.patch") 131 lines. ] [ Unable to print this part. ] [ Part 5, "" Text/PLAIN (Name: "as-name.patch") 61 lines. ] [ Unable to print this part. ] [ Part 6, "" Text/PLAIN (Name: "group-id.patch") 29 lines. ] [ Unable to print this part. ]