Dear all, The reason why there is a LINKR record has long story. refmac can read LINK and LINKR record. LINKR has reference to the description of the covalent link that must be in the dictionary (that is bond lengths, orders, angles, torsions, chiralities)
PDB LINK only says that there is a covalent (or other) bonds between two atoms. The nature of that covalent bond is implicit and has to be extracted from atom types. Even then it is ambiguous (for example it is not clear bond is double or single or is there any chirality change or change of atom types etc). Refmac LINKR meant to be explicit. Everything is defined in the dictionary. So there should not be any ambiguity. Refmac tries to interpret links from standard pdb, however there can be certain problem in interpretation of these links. i would use explicit links, design these links using jligand from ccp4 (Andrey has very good tutorials how to create links) I hope I could at least partially answer to your questions. Regards Garib On 29 May 2014, at 10:50, Eleanor Dodson <eleanor.dod...@york.ac.uk> wrote: > There are differences between the LINK pdb definition and that in REFMAC - > hence the different name LINK and LINKR > > LINKR allows you to do this: ie cross reference to a dictionary link which is > much more informative than a simple LINK record which can only define a link > distance. > > However for reasons I do not know this addition has never been adopted as > standard PDB information so there is confusion between different programs.. > Eleanor. > > > Definition of LINK with LINKR part in red. > > > > The LINK records specify connectivity between residues that is not implied by > the primary structure. Connectivity is expressed in terms of the atom names. > This record supplements information given in CONECT records and is provided > here for convenience in searching. > > Record Format > > COLUMNS DATA TYPE FIELD DEFINITION > -------------------------------------------------------------------------------- > 1 - 6 Record name "LINK " > > 13 - 16 Atom name1 Atom name. > > 17 Character altLoc1 Alternate location indicator. > > 18 - 20 Residue name resName1 Residue name. > > 22 Character chainID1 Chain identifier. > > 23 - 26 Integer resSeq1 Residue sequence number. > > 27 AChar iCode1 Insertion code. > > 43 - 46 Atom name2 Atom name. > > 47 Character altLoc2 Alternate location indicator. > > 48 - 50 Residue name resName2 Residue name. > > 52 Character chainID2 Chain identifier. > > 53 - 56 Integer resSeq2 Residue sequence number. > > 57 AChar iCode2 Insertion code. > > 60 - 65 SymOP sym1 Symmetry operator for 1st atom. > > 67 - 72 SymOP sym2 Symmetry operator for 2nd atom. > > 73 - 80 LinkID linkid Cross-reference to LINK definition > in CCP4 libraries > > > > On 28 May 2014 16:10, <herman.schreu...@sanofi.com> wrote: > Dear Remie, > > For reasons that probably only Garib understands, Refmac still uses LINKR > instead of LINK to link atoms. However (at least for Refmac) both LINK and > LINKR should work. > > After a lot of complaining in the past (also from my side), the handling of > carbohydrates in Refmac is ok. I just did some tests with N-linked > carbohydrates (NAG, MAN): after using the Make Link option in coot and saving > the file, there were regular LINK records, created by coot. After running > refmac from within coot and saving the files, the LINK records were converted > (perverted?) to LINKR records. However, they did not disappear and after > restarting coot and loading the file again, they were still there. Also my > version of pymol recognizes both LINK and LINKR records, since the > connections are shown when I load the files before and after running refmac. > > Some suggestions: check that you are using recent versions of coot, refmac > and pymol. Older versions may have problems. I don't know how you construct > your carbohydrates, but if you get the monomers, you have to delete an oxygen > atom in the link (in my case the O1 atom). Make also sure that your starting > geometry is acceptable. Just doing a real space refinement usually works > well, but sometimes the carbohydrate crashes into the protein density and you > will have to manually fit the sugar as good as possible. Some of the older > files in the PDB may have distorted carbohydrates, so here it is probably > best to build the carbohydrates again from scratch (get monomer, delete > linking oxygen) etc. > > Good luck! > Herman > > > > > > > -----Ursprüngliche Nachricht----- > Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von Remie > Fawaz-Touma > Gesendet: Mittwoch, 28. Mai 2014 16:13 > An: CCP4BB@JISCMAIL.AC.UK > Betreff: [ccp4bb] Refmac5 > > Hello everyone, > > When I refine in CCP4 a structure with Glc units attached every few of them > as a ligand and there are several of them in the same file, I start off with > a PDB that shows the LINK records between the GLC units as LINKR because I > add the links by > Extensions > Modelling > Make Link (2 atoms) in COOT. > > What does LINKR mean? why not just LINK? > > More importantly, when I refine, the output PDB file does not contain the > LINK records, why do they go away? and in PyMol I see only GLC that are close > enough to make a covalent bond stay connected, the others become detached, in > CCP4 they all show detached, but if I do a real space refinement for those > sugars of the same ligand in the output file, they come close together and > attached? > > Any suggestions? > > Thank you very much in advance. > > Remie > Dr Garib N Murshudov MRC-LMB Francis Crick Avenue Cambridge CB2 0QH UK Web http://www.mrc-lmb.cam.ac.uk, http://www2.mrc-lmb.cam.ac.uk/groups/murshudov/
