P21, twinned date & NCS refinement

From: Bosch, Juergen
Date: 27 March 2012 21:37

Dear CCP4BBers and PhenixBBers (cross posting here, since we all read both anyhow)

to the experts out there here's my question:

We have a P21 dataset with 2 molecules in the asu and a refined twin fraction of 38% according to phenix.refine using a twin law operator.

My gut feeling tells me that I can't use NCS unless I detwin the data, is that a correct assumption ?

How does phenix.refine [PDB] [mtz] twin_law="h,-k,-l" main_ncs=true would deal with this problem ?

Same question goes to Garib, it's very convenient to just specify twin in your Refmac script without further values and magic happens but what if I add NCS restrains, will Refmac treat them correctly according to the twin operator ?

Twins are confusing in real life and even more in crystals I think.

And no the data can not be processed in a higher space group, P222 results in Rmerges of >40% in the lowest resolution shell, the beta angle is 92.4 degrees in P21. And if processed in P1 we get 4 molecules per asu and a refined twin fraction of 50%, which in my eyes clearly indicates it's not P1 but really P21.

Hope to get some interesting feedback on this issue.

Thanks,

Jürgen

......................
Jürgen Bosch

----------
From: Garib N Murshudov

I would say that you should use ncs restraints in any case. NCS relates atoms and twin relates intensities. In some sense presence of twinning reduces information contents (in the limiting case the number of (effective) observervations becomes twice less) of the data and using NCS decreases the effective number of adjustable parameters. 

Without NCS some of the stats (like RvR) cannot be trusted. However you should remember that if ncs is very close to twin operators then in reciprocal space they relate two reflections exactly and in most of the cases you do not gain much and differences between ncs related molecules might be more important than their similarity. I would suggest using local ncs then global differences are retained and molecules are made locally similar.

If bet angle is 92.4 degrees (I would also check obliquity in refmac output if you are using that. In your case this number should be non-zero, meaning that twin related reflections will not coincide exactly) then I would expect splitting of spots in some directions at high resolutions. One should be careful when integrating, if only one of these spots are integrated then you may end up have several classes of reflections: low resolution and in some directions when spots overlap perfectly you have contributions from two crystals, in split spot cases each spot has contribution from single crystal.

regards

Garib

Garib N Murshudov 

----------
From: Bosch, Juergen

Thanks Garib for your input. And yes we do see some split spots. We used XDS to overcome (I hope) most problems but still intensities of perfectly overlapping reflections will be too large. Would you think it's safer to integrate the data in P1 as symmetry mates will not be merged and then solve in P1 and convert into P21 cell for further refinement afterwards ?

Jürgen

----------
From: Garib N Murshudov

Unless you have very good reason it is better to use highest possible space group (without going over). Then you do not have problem of related reflections and covariances between them, If you  go to P1 then reflection will be related with crystallographic as well as NCS as well as twin "symmetries". When you go to p21 then you at least do not have to deal with reflections related with crystallographic symmetry.  I am not sure going to P1 would solve problem of split reflections. It is a fundamental problem in data integration programs that assume there is only one lattice with one orientations. Your example shows that reality is a little bit more complicated. Split spots will cause problems in profile generations and in theory will affect quality of the data also.

If you could you should try to inegrate split spots as one (merge them) then the problem becomes similar to merohedral twinning (when spots overlap exactly). 

Regards

Garib

----------
From: Pavel Afonine

Hi Jürgen,

in phenix.refine I would do:

phenix.refine [PDB] [mtz] twin_law="h,-k,-l" main.ncs=true ncs.type=torsion

(or equivalent using the GUI).

Note, "ncs.type=torsion" will use the new NCS handling machinery that takes care of NCS automatically with no need the user to provide definitions for NCS groups. For this it is advisable to use a recent Phenix version from the nightly builds.

If resolution is ~3-2.8A and higher, then automated water update using ordered_solvent=true is good to use, so no need to waste time doing it manually.

If it is a final refinement run before PDB deposition then weights optimization using optimize_xyz_weight=true and optimize_adp_weight=true should be tried.

That's all I can tell given the information you provided.

All the best,
Pavel 

----------
From: Bosch, Juergen

Thanks Pavel for the tip, 

will the ncs.type=torsion  work with 1.7.3-928 or do I have to update ? We have >90% complete data to 2.3Å and 40% completeness to 2.1 Å.

Jürgen