First for Paul and Eugene: I am using the version of coot labelled in brown coot - 0.7 Clayton
COOT_PREFIX is /y/prog/linux/xtal/coot/coot-Linux-i386-fedora-12-gtk2-python /y/programs/xtal/coot/coot-Linux-i386-fedora-12-gtk2-python//bin/coot-real Acquiring application resources from /y/prog/linux/xtal/coot/coot-Linux-i386-fedora-12-gtk2-python/share/coot/cootrc INFO:: splash_screen_pixmap_dir /y/prog/linux/xtal/coot/coot-Linux-i386-fedora-12-gtk2-python/share/coot/pixmaps INFO:: Colours file: /y/prog/linux/xtal/coot/coot-Linux-i386-fedora-12-gtk2-python/share/coot/colours.def loaded INFO:: Using Standard CCP4 Refmac dictionary from CLIBD_MON: /y/programs/xtal/ccp4-6.3.0/lib/data/monomers/ There are 125 data in /y/programs/xtal/ccp4-6.3.0/lib/data/monomers//list/mon_lib_list.cif If it tries to read a LINKR record, it just bombs out saying no spacegroup given! Presumably it slips over into the CRYST1 record trying to find something (maybe the LINK name?) and thus ignores the CRYST1 information? And thank you to Robbie for that clarification - who should be recruited to try and make more sense of the situation? Eleanor On 26 April 2013 13:03, Robbie Joosten <[email protected]> wrote: > Hi Eleanor,**** > > ** ** > > The recent versions of Refmac work well with the records in PDB format. > According to the list of bug fixes on the website, Refmac should now take > the distance from the PDB file (it used to complain about the distance > record). Changing the 1.48 to 1.61 in the new LINK record should do the > trick. So far for the theory, in practice there are still a lot of > difficulties dealing with LINKs. **** > > ** ** > > **1) **I noticed the LINK record in the output has a different > symmetry record, are the two equivalent?**** > > **2) **The PDB generates LINK records upon deposition, even for > things that were not restrained by LINKs in Refinement, which may > misrepresent the refinement.**** > > **3) **The LINK records in the PDB give the actual distance, not the > target. Which means that you can accidentally replace good restraint > targets with poor ones, simply by loading a (previously poorly refined or > miss-annotated) PDB file.**** > > **4) **There is no consensus dictionary or a repository for LINKs at > the PDB. The CCP4 dictionary has a number of LINKs, but is quite incomplete. > **** > > **5) **Some target LINK lengths, especially in ion coordination, > vary with context even if the involved atoms are the same. **** > > ** ** > > Cheers,**** > > Robbie**** > > ** ** > > ** ** > > *From:* CCP4 bulletin board [mailto:[email protected]] *On Behalf Of > *Eleanor > Dodson > *Sent:* Friday, April 26, 2013 13:30 > *To:* [email protected] > *Subject:* [ccp4bb] LINK or LINKR**** > > ** ** > > Is there any consensus about the accepted format for this? **** > > I believe Garib uses LINKR to add a link name to the record, (cant find a > description in the documentation though???) > > but also in the documentation REFMAC is said to provide a link between > symmetry related like this**** > > with the target distance here**** > > LINK 1 P DG A 1 1.61000 O3' DC A 2 > 1555 6554**** > > i**** > > But REFMAC a) ignores the given distance and b) writes it out as : > LINK P DG A 1 O3' DC A 2 1555 2554 > 1.48**** > > This is in agreement with the PDB definition but with a wrong distance - > presumably derived in the innards of the dictionary:**** > > ** ** > > PDB LINK definition**** > > 12345678901234567890123456789012345678901234567890123456789012345678901234567890**** > > LINK O GLY A 49 NA NA A6001 1555 1555 > 2.98 **** > > LINK OG1 THR A 51 NA NA A6001 1555 1555 > 2.72 > 12345678901234567890123456789012345678901234567890123456789012345678901234567890**** > > LINK O GLY A 49 NA NA A6001 1555 1555 > 2.98 **** > > LINK OG1 THR A 51 NA NA A6001 1555 1555 > 2.72 **** > > ** ** > > coot seems to refuse to read the LINKR at all! > > **** > > Confused Eleanor**** >
