Hi, On Tue, May 15, 2018 at 02:21:59PM +0000, Robbie Joosten wrote: > A link describes a chemical bond between two residues. With each > LINK modifications of the residues are described (e.g. leaving atoms > and, in this case, changes of local chemistry such as bond orders).
I guess that is not strictly true for the official PDB format description e.g. at http://www.wwpdb.org/documentation/file-format-content/format33/sect6.html#LINK where we have The LINK records specify connectivity between residues that is not implied by the primary structure. Connectivity is expressed in terms of the atom names. They also include the distance associated with the each linkage following the symmetry operations at the end of each record. "Connectivity" doesn't explicitly mean a "chemical bond", although further down we have The atoms involved in bonds between HET groups or between a HET group and standard residue are listed. and other points talk about "linkages" and "bonding". So maybe not completely clear what is meant here - but let's assume that some kind of chemical relation is intended (bond, coordination, salt bridge). However, PDB entries themselves contain a vast amount of LINK records that are clearly auto-generated by some software step after deposition: this step seems to use a simple 3.5A cut-off criteria to list all atoms in close contact. That's why there are all those LINK records involving HOH waters - and we clearly don't want to introduce a bond restraint to those waters. Anyway, apart from the potential issues with LINK records in deposited PDB entries, those records in PDB files under active refinement don't really hold a description about the linkage type - only if a program is either writing content beyond the default length of 78 characters or by writing non-standard LINK records, i.e. missing the SymOP items and putting something else there. This can make those LINK records quite problematic when moving between different programs - the non-standard LINKR record used by REFMAC (?) seems a cleaner way to me, being obviously non-standard. Cheers Clemens > Each LINK type has a unique identifier that points to the descriptions in the > CCP4 dictionary. Did you add those names (HEC-something, I don’t know them by > hart)? And is your CCP4 up to date? > > Cheers, > Robbie > > Sent from my Windows 10 phone > > ________________________________ > From: CCP4 bulletin board <CCP4BB@JISCMAIL.AC.UK> on behalf of Eugene Osipov > <e.m.osi...@gmail.com> > Sent: Tuesday, May 15, 2018 2:53:49 PM > To: CCP4BB@JISCMAIL.AC.UK > Subject: Re: [ccp4bb] Problems with HEC in CCP4 > > Hi Robbie, > I thought LINK just adds another bond restrain to the refinement procedure > and does not affect already existing restrains in library cif file. Am I > wrong? > Also, what do you mean by "modify the chemistry"? > Just to test your suggestion, I have added LINKs for heme c vynil groups in > 4qo5 and ran refinement in refmac 5.8. I took F(+) from deposited cif file as > F and SigF(+) as SIGF. After refinement HEC601 and HEC604 have incorrect > position of CBC atom. > Note: I took 4qo5 just as example of cytochrome c to show issues with HEC and > do not intend to insult authors of original paper. > > 2018-05-15 12:00 GMT+03:00 Robbie Joosten > <robbie_joos...@hotmail.com<mailto:robbie_joos...@hotmail.com>>: > Addendum: > > 4qo5 actually lacks the right LINK records altogether. It will only work if > you add these by hand. Perhaps you should ask the depositors or the PDB to > add the appropriate LINK records. > > Cheers, > Robbie > > > -----Original Message----- > > From: CCP4 bulletin board > > <CCP4BB@JISCMAIL.AC.UK<mailto:CCP4BB@JISCMAIL.AC.UK>> On Behalf Of Robbie > > Joosten > > Sent: Tuesday, May 15, 2018 10:51 > > To: CCP4BB@JISCMAIL.AC.UK<mailto:CCP4BB@JISCMAIL.AC.UK> > > Subject: Re: [ccp4bb] Problems with HEC in CCP4 > > > > Hi Eugene, > > > > The problem is not in the HEC.cif file but with the LINKs which modify the > > chemistry. These were fixed a while ago and the LINKs were added to the > > CCP4 dictionary. I thought these were released already. If not, they will be > > soon. > > > > Cheers, > > Robbie > > > > > -----Original Message----- > > > From: CCP4 bulletin board > > > <CCP4BB@JISCMAIL.AC.UK<mailto:CCP4BB@JISCMAIL.AC.UK>> On Behalf Of > > Eugene > > > Osipov > > > Sent: Tuesday, May 15, 2018 10:36 > > > To: CCP4BB@JISCMAIL.AC.UK<mailto:CCP4BB@JISCMAIL.AC.UK> > > > Subject: [ccp4bb] Problems with HEC in CCP4 > > > > > > Dear CCP4 developers, > > > please fix errors with heme c dictionary file HEC.cif. > > > Edward Berry described this problem in detail 4 years ago: > > > https://www.mail-archive.com/ccp4bb@jiscmail.ac.uk/msg36393.html > > > This error already affects deposited entries, e.g.: 4QO5 clearly > > > contains errors in vynil groups of heme c. > > > > > > > > > -- > > > > > > Eugene Osipov > > > Junior Research Scientist > > > Laboratory of Enzyme Engineering > > > A.N. Bach Institute of Biochemistry > > > Russian Academy of Sciences > > > Leninsky pr. 33, 119071 Moscow, Russia > > > e-mail: e.m.osi...@gmail.com<mailto:e.m.osi...@gmail.com> > > > <mailto:e.m.osi...@gmail.com<mailto:e.m.osi...@gmail.com>> > > > > -- > Eugene Osipov > Junior Research Scientist > Laboratory of Enzyme Engineering > A.N. Bach Institute of Biochemistry > Russian Academy of Sciences > Leninsky pr. 33, 119071 Moscow, Russia > e-mail: e.m.osi...@gmail.com<mailto:e.m.osi...@gmail.com> -- *-------------------------------------------------------------- * Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com * Global Phasing Ltd., Sheraton House, Castle Park * Cambridge CB3 0AX, UK www.globalphasing.com *--------------------------------------------------------------
