:: took a working dataset and increased (only) the error on unit cell
dimensions in the instruction file for the final round of full matrix :: least
squares refinement in shelxl. Sure enough, the errors on the bonds and angles
shot up. I was more careful
Question: did you change the unit cell d
I'm fairly sure that the 300-ish micron focus on my old (and retired) Rigaku
RuH3R home system - a perfectly good workhorse - was consider micro-focus by
precisely nobody.
Phil Jeffrey
Princeton
From: CCP4 bulletin board on behalf of Gianluca Santoni
Sent: W
"Very decent" means different things to different people. Is your Rmerge < 20%
in the 0.84 Å shell ? If so that's a small molecule quality data set and
something like that should solve relatively straightforwardly with e.g. SHELXT.
However the classical program would be SHELXD and perhaps a C
Juliana,
I think if you compare otherwise equivalent refinement runs in phenix.refine
with
refinement.input.xray_data.outliers_rejection=True (the default)
and
refinement.input.xray_data.outliers_rejection=False
then this will tell you if there's any meaningful difference in the refinement
sta
Jacob,
If you fine slice and everything is then a partial, isn't that *more* sensitive
to lack of synchronization between the shutter and rotation axis than the
wide-frame method where there's a larger proportion of fulls that don't
approach the frame edges (in rotation space) ? Especially if
Mohamed,
You always list the sequence of what's actually in the crystal, e.g. 1-105.
(Not: what's in the model or what the sequence of the full length protein is).
Make sure that if there's any lingering residues from any affinity/purification
tags they get included in the sequence too.
Phil
Hello Yafang,
The answer lies in the fact that you used HKL2000. Scalepack has a long
standing "feature" where it reports Rmerge > 100% as zero. Quite why they do
that is a mystery, but your Rmerge in the outermost shell is NOT zero - the
Rmerge for the lower resolution shells will show up as
Nat Echols wrote:
> Personally, if I need to change a chain ID, I can use Coot or pdbset or many
> other tools. Writing code for
> this should only be necessary if you're processing large numbers of models,
> or have a spectacularly
> misformatted PDB file.
Problem. Coot is bad at the chain l
> I.e. programs would look like this
>
> ---
> GRAB protein FROM FILE "best_model_ever.cif";
> SELECT CHAIN A FROM protein AS chA;
> SET chA BFACTORS TO 30.0;
> GRAB data FROM FILE "best_data_ever.cif";
> BIND protein TO data;
> REFINE protein USING BUSTER WITH TLS+ANISO;
> DROP protein INTO FILE "
Are all the APIs open source ? I was under the impression that CCP4 had moved
away from that, which might justifiably reduce interest in any
limited-availability API.
Phil Jeffrey
Princeton
From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of J
Top 20 HETNAM entries based on 58,469 PDB entries at better than 2.5 Angstrom
resolution (arbitrary cut):
Number of entries in histogram: 14864
Total number of instances : 195481
0 14502 0.0742 GOL(glycerol)
1 10952 0.0560 SO4
2 8064 0.0413 ZN
3 7628 0.0390 MG
4 6930
That sounds like the bug in Phenix.refine v1.8 that a few of us encountered -
updating to the latest release will help.
Actually wasn't so much a bug but a "feature", albeit not the best one
imaginable. Anyone using older v1.8 versions should update.
---
Phil Jeffrey
Princeton
On Nov 2, 2012,
Hi Tim,
While I use Scalepack2mtz (not from the gui) all the time, Scalepack has the
unfortunate feature that once Rsym > 1.0 it gets reported as 0.0. Now that I'm
exploring higher resolution limits along the lines of the recent Karplus and
Diederichs paper (Science Vol. 336, pp. 1030-33 (2012
13 matches
Mail list logo
