I suspect most (if not all) refinement software now have a nice way to deal
with NCS in refinement locally. Technically, this means you can use NCS
restraints at any resolution and software should be able to be careful and
not wipe out local differences between NCS copies. In phenix.refine this is
done by parameterizing NCS restraints in torsion angle space and using
top-out potential as restraint target, all described here in great details:

http://journals.iucr.org/d/issues/2014/05/00/rr5054/rr5054.pdf

Pavel

On Mon, Apr 24, 2017 at 5:42 AM, Clemens Vonrhein <
vonrh...@globalphasing.com> wrote:

> Dear all,
>
> On Mon, Apr 24, 2017 at 08:15:57AM +0000, Bert Van-Den-Berg wrote:
> > Not quite sure what you mean but I suppose you refined with NCS
> > restraints and the red bar means that your chains in those regions
> > are not identical. I would turn NCS restraints off during
> > refinement, with your resolution there is no real good reason to
> > include them.
>
> While that might have been understandable advice in the days when we
> used purely superposition/rmsd-based NCS restraints/constraints (and
> true differences between NCS-related copies became a nightmare to
> define/model), this should no longer be true for the majority of
> refinement programs out there.
>
> We now use much "softer" NCS restraints that allow for local
> similarity - which at the same time allows for large differences like
> domain/loop movements etc. Most programs will at the same time detect
> local outliers and prune those. See e.g. [1] for such an
> implementation in BUSTER [2] (-autoncs flag) ... I'm sure other
> programs use similar approaches.
>
> Anyway, the traditional recommendation to drop NCS restraints at later
> stages of refinement was nearly always based on procedural
> complexities and should no longer hold true: there is no reason to
> drop NCS restraints at any (within reason) resolution I think. Of
> course, the real differences need to be taken care of by exclusion
> (what we call 'pruning', mostly done automatically anyway).
>
> Cheers
>
> Clemens
>
> [1] Smart, O. et al (2012). Acta Cryst. D68, 368-380.
> [2] http://www.globalphasing.com/buster/
>

Reply via email to