On Tue, 17 Jul 2012 06:26:39 +, LEGRAND Pierre
pierre.legr...@synchrotron-soleil.fr wrote:
Hi Jason,
To answer your initial question about overlaps versus finer slicing, you can
get a good description of the problem in Fig10
of Z. Dauter article Data-collection strategies (open
Hi Jason,
I looked at the part of FRAME.cbf you posted, and I'd say it looks ok (i.e.
nothing to worry about).
Some overlap of a reflection doesn't matter much; if its full profile is not
available then INTEGRATE replaces the missing intensity by an estimate based on
the known fraction of
] de la part de Jason Busby
[j.bu...@auckland.ac.nz]
Date d'envoi : mardi 17 juillet 2012 06:04
À : CCP4BB@JISCMAIL.AC.UK
Objet : Re: [ccp4bb] Large unit cell, overlaps
Hi,
Ok, IDXREF.LP shows that it was only using 1-262. I tried running COLSPOT and
IDXREF again, and it picks the same
De : CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] de la part de LEGRAND Pierre
Date d'envoi : mardi 17 juillet 2012 08:26
À : CCP4BB@JISCMAIL.AC.UK
Objet : [ccp4bb] RE : [ccp4bb] Large unit cell, overlaps
Hi Jason,
To answer your initial question about overlaps versus
For large unit cells, one must take particular care with the X-ray beam and the
orientation of the crystal. The latter has already been mentioned in previous
response. For the beam, some things to do are:
1. Make crystal smaller.
2. Make beam smaller (use a smaller collimator size).
3. Reduce
The cell predictions look like they're overlapping but the spots are not. At
first glance it looks like the unit cell is incorrect and is too large.
You seem to have intense spots mixed in with weak spots at the same
resolution. Smells like multiple unit cells / cracked crystal (which if
Hi,
The autoindexing picks this unit cell pretty much unambiguously, and the
profiles look reasonable. These are crystals of a very large heterodimer (2177
residues), and this unit cell would have 2 heterodimers and 56% solvent, which
seems reasonable. Scaling and merging produce reasonable
Hi,
This is what I thought when collecting the data - the spots did not look to be
overlapping. I have actually got 4 datasets (native, mercury, iodide and
platinum soaks) and they all index as the same spacegroup and unit cell (the Pt
soak being slightly larger unit cell). This is of a
grep SPOT_RANGE IDXREF.LP should provide you information about that. No idea
what the default would be.
How about pointless ?
Something else which might buy you a bit of signal is
NUMBER_OF_PROFILE_GRID_POINTS_ALONG_ALPHA/BETA=13
NUMBER_OF_PROFILE_GRID_POINTS_ALONG_GAMMA=13
The default for
From the statistics you posted, it seems like the integration went quite
reasonably. There is a slight undercompleteness in the high resolution bin (82%
is a bit on the low end but since this is for phasing I'd expect a traceable
map in light of this).
Do the diffraction images indicate very
Hi,
Ok, IDXREF.LP shows that it was only using 1-262. I tried running COLSPOT and
IDXREF again, and it picks the same unit cell.
Pointless picks Pmmm and picks 2 definite screw axes, and one possible (p
~0.5), so either P22121 or P212121.
I did change the number of grid points to 13 on my
I'd run
INTEGRATE(REFINE)=CELL
CORRECT(REFINE)=CELL
and fixing your distance first. Then once XDS is done copy GXPARM.XDS to
XPARM.XDS and enter those refined values into your XDS.INP script. Once you
have a stable cell you can refine the distance and later fix that one. Moving
distance is a
Hi Jason,
don't really think that the overall scaling stats look very good. Even for such
a long unit cell, we have plenty of in-house data (even with a smaller
detector) with much lower Rmerge, typically below 0.15. Possibly monoclinic
with beta close to 90deg? This might also explain the
I second Jürgen's suggestion of fixing the distance -- this is often quite
helpful when dealing with difficult datasets, at least in my experience
And this goes without saying, but also double check your beamcenter and try
masking the beamstop (using UNTRUSTED_ELLIPSE) if you haven't done so
14 matches
Mail list logo
