Dear Developers,
Recent versions of sftools appear to ignore the order of columns given in
the 'write' command (and keep the order of the input mtz file in the
output as well). The problem persists even with the executable distributed
with v.6.2.0.
Example :
_
Dear all,
Is it reasonable to refine occupancy in phenix at 2.2 A resolution?
Thank you.
Mike Colaneri
Dear all,
Is it reasonable to refine occupancy in phenix at 2.2 A resolution?
Thank you.
Mike Colaneri
Depends on the kind of atom, I suspect. Also on whether the occupancy is
refined for individual atoms or jointly for e.g. a disordered structural
element (a loop or mobile domain)
Artem
On Jun 2, 2012 10:16 PM, "Michael Colaneri" wrote:
> Dear all,
>
> Is it reasonable to refine occupancy in phe
Could you please give me a reference to the "K & D paper"? Without reading it,
I do not see a problem with Rmerge going to infinity in high resolution shells.
Indeed, I was taught at school that the crystallographic resolution is defined
as a minimal distance between two peaks that can be distin
I looked at those abstracts, thanks. Now I know that the "K & D paper" means,
promises to read it.
Well, I agree that Rmerge should be replaced with Rrim (redundancy independent
merging factor). Was not Z. Otwinowski first to use it in his scalepack? I
agree, dependence on the number of measure