twin refinement in refmac

From: wtempel
Date: 2 March 2012 02:00
Dear CCp4ers,

A good morning to everyone.

Today, I have a structure that I initially refined in space group P6522, 1mol/asu.

Scaling stats (scalepack): 2.30-2.26A: Rsym=99.9%; <I>/<sigma> > 3

2.61-2.55A: Rsym=39.6%, <I>/<sigma> > 10

50.00-6.13: Rsym=6.4%

Some mild anisotropy in the resolution limits is apparent on the diffraction images. Say, visible spots at 2.2A in one direction, 2.6A in the other.

Rfree, using data to 2.3A, was stuck in mid-30%s. The map appears like 3.5A resolution, with some difference density for loops that cannot be interpreted with reasonable geometry.

Rsym is very similar for data scaled in P3, in all resolution shells. Xtriage does not suggest merohedral twinning.

Nevertheless, I extended my free flags in sftools from P6522 to P32 and cad'd them to amplitudes merged in spacegroup P32. Correspondingly, I expanded my model to a homotetramer and ran Refmac with amplitude based twinning. (Would this be a reasonable input to twin refinement?)

From the output coordinates:

REMARK   3  TWIN DETAILS

REMARK   3   NUMBER OF TWIN DOMAINS  :    4

REMARK   3      TWIN DOMAIN   :    1

REMARK   3      TWIN OPERATOR :  H,  K,  L

REMARK   3      TWIN FRACTION : 0.269

REMARK   3      TWIN DOMAIN   :    2

REMARK   3      TWIN OPERATOR : -K, -H, -L

REMARK   3      TWIN FRACTION : 0.171

REMARK   3      TWIN DOMAIN   :    3

REMARK   3      TWIN OPERATOR :  K,  H, -L

REMARK   3      TWIN FRACTION : 0.258

REMARK   3      TWIN DOMAIN   :    4

REMARK   3      TWIN OPERATOR : -H, -K,  L

REMARK   3      TWIN FRACTION : 0.302

Does this establish twinning versus underestimated symmetry? And what do I need to know about my free-R? Did refmac assign a new flag? Whereas the output file's flags are all 1s and 0s, the input file had 0 ... 19. During the first run, Rfree dropped to <28%. But on a subsequent run, Rfree was stuck >30% when I used the initial job's output MTZ.

Many thanks in advance for your helpful comments.

Wolfram Tempel

----------
From: Pavel Afonine
Hi Wolfram,

a few points:

- R-factors in twin refinement vs non-twin refinement are not directly comparable:

G.N. Murshudov, Appl. Comput. Math., V.10, N.2, 2011, pp.250-261

http://www.science.az/acm/V10,%20N2,%202011,%20pdf/250-261.pdf

- did you make sure free-R flags assigned "having twinning in mind" (what phenix.refine always does)? Otherwise you have a risk of having this:

see page 14 here:

http://phenix-online.org/presentations/latest/pavel_validation.pdf

Pavel

----------
From: Randy J. Read
I'm worried when you say that you use the initial job's output MTZ. Refmac replaces F with a detwinned F in the output file so you wouldn't be refining against your measured data in the subsequent round.

Best wishes

Randy Read

----
Randy J. Read

----------
From: arka chakraborty
Hi all,

I will like to know, as a follow up of what Prof. Randy Read said, what should be done to do the refinement against the measured data and not the detwinned F( which refmac outputs in the mtz after twin refinement), during subsequent refinements. And also, I would like to know how to ensure that the free R generated takes twinning into account if I am not using phenix.

Thanks in advance,

Regards,

ARKO

--

ARKA CHAKRABORTY

CAS in Crystallography and Biophysics

University of Madras

Chennai,India

----------
From: Randy Read

Garib may have more to say, but the first point would be to always include the original data file as your input MTZ file for any cycle of refinement, whether you're using Refmac in CCP4 or phenix.refine.  (In phenix.refine, if you assign the R-free data the first time you do refinement, it will produce a file containing all the information used in that cycle of refinement, including the new R-free flags and possibly any Hendrickson-Lattman coefficients, and you should use that file for all subsequent refinements.)

As for whether R-free takes twinning into account, I think it's fair to say that all the refinement programs that handle twinning will do this appropriately.

Regards,

Randy Read

------

Randy J. Read

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

1) You should use measured data (after scala/aimless/truncate). In general there may not be one to one relationship between observed data and asymmetric unit (e.g. non-merohedral twinning) and it would not be possible to bring input data to output file. Use original data

2) Internally refmac groups reflection into classes. All twin related reflections belong to one class. In the example you give four reflections belong to one class. FreeR is property of the class not individual relfections. I.e. all twin related reflections belong either to free or working class. If your input data has this property then output should also have this. In the output file there will be 0 (for free) and 1 (working)

3) At early stages it is not easy to factorise twin and underestimated symmetry. It seems that L-test is the best way of making decision if you "crystals" are twinnined. If you collect data from many crystals and merge them then you artificially twin (or increase twinning). Using pointless to index all datasets consistently may sort some of the problems 

4) In this case it seems that you may need to reindex. Largest twin domain is not the first one

Regards

Garib

Garib N Murshudov 

----------
From: Steiner, Roberto

On 2 Mar 2012, at 08:01, arka chakraborty wrote:

Hi all,

I will like to know, as a follow up of what Prof. Randy Read said, what should be done to do the refinement against the measured data and not the detwinned F( which refmac outputs in the mtz after twin refinement), during subsequent refinements.

Operationally, don't put in the "MTZ in" field of the GUI something that Refmac generated for you in a previous run as "MTZ out" file. Always use as "MTZ in" your original data file.

And also, I would like to know how to ensure that the free R generated takes twinning into account if I am not using phenix.

Refmac does take in consideration the twin law(s) when handling free reflections . This is the case even if you have generated your free reflections randomly. Internally Refmac will modify your Free set in such a way that twin related reflections are in the same group (free or working) --> classes mentioned by Garib

The good thing about this is that twin-related reflections are handled properly during refinement irrespective of your Free-set choice. 

The bad thing (Garib please correct me if I am wrong here) is that you might end up depositing a Free set which is not that actually used in refinement.

Best wishes

Roberto

----------
From: arka chakraborty
Hi all,

Thanks for the express replies. Your insights along with the article by Prof. Garib pointed to by Prof. Pavel completes the story for me.

Regards,

ARKO

----------
From: Eleanor Dodson
Is this twinning or several crystals indexed according to different conventions? You usually see evidence of twinning for each crystal if it is really there..

Trigonal data can be indexed as h,k,l k,h,-k -h,-k,l or -k,-h,-l of course so you have a 75% chance of getting the 2nd crystal on a different convention than the first.. POINTLESS checks for this if you give it pairs of input files and does a good job in selecting the same indexing convention - providing of course the twinning isnt present.

I would be suspicious because

a) I have been convinced by having more than 2 twin domains b) when there is twinning the data analysis on each crystal seperately shows it up.

Eleanor

--
Professor Eleanor Dodson