[phenixbb] Geometry Restraints - Anisotropic truncation

[Pavel Afonine]

Hi,

we discussed this with Randy the other day.. A couple of copy-pasts from 
that discussion:

In general, given highly anisotropic data set:

1) maps calculated using all (unmodified) data by phenix.refine, 
phenix.maps and similar tools are better than maps calculated using 
anisotropy truncated data. So, yes, for the purpose of map calculation 
there is no need to do anything: Phenix map calculation tools deal with 
anisotropy very well.

2) phenix.refine refinement may fail if one uses original anisotropic 
data set. This is probably because the ML target does not use 
experimental sigmas (and anisotropy correction by UCLA server is nothing 
but Miller index dependent removing the data by sigma criterion - yeah, 
that old well criticized practice of throwing away the data that you 
worked hard to measure!). May be using sigmas in ML calculation could 
solve the problem but that has to be proved.

Nat: I added the code that does anisotropy truncation a wile ago (see in 
miller class - there are a couple of methods that do it) but this is not 
exposed to the user level.

Pavel


On 4/29/12 6:30 AM, Leonid Sazanov wrote:
> Hi, so will we see now the possibility to apply anisotropic resolution 
> limits truncation in Phenix?
> Despite the fact that a lot of people use UCLA server, there is still 
> no possibility to do this in any major crystallographic software, AFAIK.
> Phaser does the scaling, but no truncation, and noise sitting in those 
> regions where there is no signal, is a real culprit.
> Large SIGFs there do not resolve the problem completely.
> Thanks.
>
>
> >>>>>>
> Message: 4
> Date: Wed, 25 Apr 2012 09:05:57 -0400
> From: Mario Sanches <mariosan at gmail.com>
> To: PHENIX user mailing list <phenixbb at phenix-online.org>
> Subject: [phenixbb] Geometry Restraints - UPDATE
> ..........
> It turns out that the reason to my nightmares was a highly anisotropic
> dataset. When I tried to fix geometry related problems in coot,
> phenix.refine was twisting the geometry back again, probably because 
> it was
> trying to fit a lot of noise due to the anisotropy. Everything was 
> getting
> worst, geometry, clashscore, and Ramachandran.
>
> Pavel finally corrected it by using this server:
> http://services.mbi.ucla.edu/anisoscale/
>
> ............
>
>