Dear All, I'm with Dale on this one. It's better to have a standard and roll with it, than allow for ambiguity. The discussion just happened to start with a rather silly example as Tim pointed out. The ligand 1N1 (http://ligand-expo.rcsb.org/reports/1/1N1/1N1_D3L1.gif) is a better example: The atoms N5 and N6 can have inverted chirality. If it is just one of the two, then the molecule is distorted (IFF the restraint file is correct!). If both have inverted chirality than the problem can be fixed by label swapping. Hacking the restraint file to allow both positive and negative chirality would allow you to distort the molecule.
Cheers, Robbie > -----Original Message----- > From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of > Tim Gruene > Sent: Friday, July 13, 2012 10:59 > To: CCP4BB@JISCMAIL.AC.UK > Subject: Re: [ccp4bb] Chiral volume outliers SO4 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear all, > > I am surprised by the discussion about "chiraliy" of an utterly > centrosymmetric molecule. Shouldn't the four Oxygen atoms be at least > from a QM point-of-view to indistinguishable? What reason is there to > maintain a certain 'order' in the human-induced numbering scheme? > > Cheers, > Tim > > On 07/13/12 00:22, Dale Tronrud wrote: > > While this change has made your symptom go away it is stretching it a > > bit to call this a "fix". You have not corrected the root problem > > that the names you have given your atoms do not match the convention > > which is being applied for SO4 groups. Changing the cif means that > > you don't have to worry about it, but people who study such details > > will be forced to deal with the incorrect labels of your model in the > > future. > > > > Wouldn't it just be easier to swap the names of two oxygen atoms in > > each SO4, leaving the cif alone? Your difficulties will go away and > > people using your model in the future will also have a simpler life. > > > > This labeling problem is not new. The fight to standardize the > > labeling of the methyl groups in Valine and Leucine was raging in the > > 1980's. Standardizing the labels on the PO4 groups in DNA/RNA was > > much more recent. It helps everyone when you know you can overlay two > > models and have a logical solution without a "rotation matrix" with a > > determinate of -1. > > > > Besides, you will continue to be bitten by this problem as you use > > other programs, until you actually swap some labels. > > > > Dale Tronrud > > > > On 07/12/12 15:00, Joel Tyndall wrote: > >> Hi all, > >> > >> Thanks very much to all who responded so quickly. The fix is a one > >> liner in the SO4.cif file (last line) > >> > >> SO4 chir_01 S O1 O2 O3 both > >> > >> which I believe is now in the 6.3.0 release. > >> > >> Interestingly the chirality parameters were not in the SO4.cif file > >> in 6.1.3 but then appeared in 6.2.0. > >> > >> Once again I'm very happy to get to the bottom of this and get it > >> fixed. I do wonder if it had become over parametrised. > >> > >> Cheers > >> > >> Joel > >> > >> > >> > >> -----Original Message----- From: CCP4 bulletin board > >> [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Robbie Joosten Sent: > >> Thursday, 12 July 2012 12:16 a.m. To: CCP4BB@JISCMAIL.AC.UK > >> Subject: Re: [ccp4bb] Chiral volume outliers SO4 > >> > >> Hi Ian, > >> > >> > >>>> @Ian: You'd be surprised how well Refmac can flatten sulfates if > >>>> you have a chiral volume outlier (see Figure 1d in Acta Cryst. D68: > >>>> 484-496 > >>> (2012)). But this is only because the 'negative' volume sign was > >>> erroneously used > >> in > >>> the chiral restraint instead of 'both' (or better still IMO no > >>> chiral > >> restraint at > >>> all), right? If so I don't find it surprising at all that Refmac > >>> tried to > >> flip the > >>> sulphate and ended up flattening it. Seems to be a good illustration > >>> of the GIGO (garbage in - garbage out) principle. > >>> Just because the garbage input in this case is in the > >> official > >>> CCP4 distribution and not (as is of course more commonly the > >>> case) perpetrated by the user doesn't make it any less garbage. > >> The problem is that in the creation of chiral volume targets > >> chemically equivalent (groups of) atoms are not recognized as such. > >> So any new or recreated restraint files will have either 'positiv' or > >> 'negativ' and the problem starts all over again. > >> That is why it is better to stay consistent and choose one chirality > >> (the same one as in the 'ideal' coordinates in the PDB ligand > >> descriptions). This will also make it easier compare ligands after > >> aligning them (this applies to ligands more complex than sulfate). > >> Obviously, users should not be forced to deal with these things. > >> Programs like Refmac and COOT should fix chiral volume inversions for > >> the user, because it is only relevant inside the computer. That is > >> the idea of chiron, just fix these 'problems' automatically by > >> swapping equivalent atoms whenever Refmac gives a chiral volume > >> inversion warning. It should make life a bit easier. > >> > >>> The point I was making is that in this and similar cases you don't > >>> need a > >> chiral > >>> restraint at all: surely 4 bond lengths and 6 bond angles define the > >> chiral > >>> volume pretty well already? Or are there cases where without a > >>> chiral restraint the refinement still tries to flip the chirality (I > >>> would fine > >> that hard to > >>> believe). > >> I agree with you for sulfate, and also for phosphate ;). I don't know > >> what happens in other compounds at poor resolution, when bond and > >> angle targets (and their SDs) are not equivalent. I guess that some > >> angle might 'give way' before others. That is something that should > >> be tested. I have a growing list of chiral centers that have this > >> problem if you are interested. > >> > >> Cheers, Robbie > > > > - -- > - -- > Dr Tim Gruene > Institut fuer anorganische Chemie > Tammannstr. 4 > D-37077 Goettingen > > GPG Key ID = A46BEE1A > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iD8DBQFP/+M0UxlJ7aRr7hoRAvcqAJ9nuBmSmc2qVyMf17T76stvbqmfEQCfQI > Do > v9xoSL/c7LGAKFe3B5Rk9Zc= > =PSch > -----END PGP SIGNATURE-----
