On 13 December 2011 17:59, James Holton jmhol...@lbl.gov wrote:
A small but potentially important correction:
FC_ALL PHIC_ALL from REFMAC are indeed the calculated structure factor of
the coordinates+bulk_solvent, but AFTER multiplying by the likelihood
coefficient D (as in 2*m*Fo-D*Fc ).
PHIC wont do any harm - you may need it for various reasons - I use it
mostly as input for a DANO map to check out possible metal sites..
The reason for not using a refmac output mtz as input for the next run is
1) the refmac output Fobs has been scaled by the anisotropic scale so
all
On Tue, 2011-12-13 at 02:31 +, Yuri Pompeu wrote:
Hi Ed,
I just had a chance of looking at your comment more closely.
You are right it only uses PHIC if in refmacs set up you choose to refine
with prior phase information -AFAIU.
So what exactly is the info contained in the output
A small but potentially important correction:
FC_ALL PHIC_ALL from REFMAC are indeed the calculated structure factor
of the coordinates+bulk_solvent, but AFTER multiplying by the likelihood
coefficient D (as in 2*m*Fo-D*Fc ). So, if you subtract ( FC_ALL
PHIC_ALL ) from ( FC PHIC ) you will
This is very uncommon...
Can you look at the final plot of R and Rfree against resolution.
Sometimes there is an awful hiccup somewhere -
ice rings?
high resolution data somewhat fictional -
low resolution data saturated and also somewhat fictional ..
I also check the completeness which is uin
Hi Ed,
I just had a chance of looking at your comment more closely.
You are right it only uses PHIC if in refmacs set up you choose to refine with
prior phase information -AFAIU.
So what exactly is the info contained in the output refmacX.mtz besides map
coefficients for COOT? If it is not just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Yuri et al.,
I like the fact that one must not use the output mtz-file from refmac as
input to the next round of refinement. It encourages to think about why
this is and then makes you realise what your data really are: the result
of data
On Sun, 2011-12-11 at 05:28 +, Yuri Pompeu wrote:
In refmac however the newly generated refmacX.mtz file contains phase
info as PHIC calculated from your model. Using this for subsequent
rounds of refinement results in terrific looking maps as they are now
biased (even more so) by the
Precisely, one should not use it! I have seen people do it either
because they dont fully understand what is going on or are not at all
familiar with the documentation.
In phenix the output .mtz contains Fo plus x% Rfree flag=1, so one may
try and do this for refmac because of one of the two
PHENIX has an otpion under the reflection editor program that will create R
flags that are compatible with ccp4 programs.
Another point worth mentioning is in phenix.refine it is appropriate to use the
data.mtz files generated each round of refinement, as these are the raw data
plus the Rfree
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Petr,
there may be a couple of reasons, e.g.
- - your data are not really 1.1A, but you simply integrated a lot of noise
- - you entered some odd command or another option which allows refmac5
such a deviation
- - your model is incomplete
- -
Hi Everybody,
First off, thanks for the replies. They definitely fixed my problem. It
was indeed as Garib Murshudov said. The flags got swapped, and therefore
the percentage of Rfree reflections were 95%.
So, if Rfree is created from CCP4.use Rfree flags with a value of 0
and a value of 1 if
Hi Christopher,
just a remark: for phenix.refine it does not matter where the flags come
from and what is the test/work value since it automatically scores the
values in the flags array and guesses the right one. Still one can imagine
corner case, so it's good to be careful -:)
Pavel
On Fri,
On Fri, 2011-12-09 at 05:45 -0800, Pavel Afonine wrote:
just a remark: for phenix.refine it does not matter where the flags
come from and what is the test/work value since it automatically
scores the values in the flags array and guesses the right one. Still
one can imagine corner case, so
Hi Ed,
changes like this generate more confusion then good, I guess. Current
phenix.refine behavior does not create any problem for phenix.refine users,
so I don't feel a strong reason for changing anything. It's not just a
flipping the flag value somewhere, but it's updating the documentation,
Christopher,
if you send me the input PDB and data files (off-list, of course) I will
have a close look and then explain what exactly happens and why. I also
promise to post the summary on this mailing list (without revealing the
identity of your structure, of course).
If you send me the command
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Christopher,
if your R/Rfree from Refmac5 really are 10% vs. 18%, you might simply be
looking at an electron density map with strong model bias, i.e. the map
shows the features of the model and not of the data. Although at 1.1A
resolution this
are you sure that you are using the original input intensities for the REFMAC
map calculation (and the refinement run) and not the output ones of the
(previous) run?
if you are not, you may have model bias, and Rfree can be fooled, especially
with NCS (if you have it).
- or perhaps anisotropic
In addition to the remarks of Mark and Tim, could you make sure that you are
refining in Refmac with the correct flag for the Rfree set (value = 0)? In
Phenix, this is the opposite: the value is 1 for test reflections and 0 for
work reflections. So going from a PHENIX environment to Refmac,
Dear Tim,
I agree with you completely. The question then becomes why does the automatic
weighting scheme in refmac allow R and R-free to run away from each other by 8%
in a 1.1 A resolution structure?
Petr
On Dec 8, 2011, at 6:50 PM, Tim Gruene wrote:
-BEGIN PGP SIGNED MESSAGE-
In a non-computational capacity would also suggest perhaps resequencing
your clone. Occasionally the published sequences are off, the specific base
is polymorphous or there is also the possibility that you introduced a
mutation somewhere. That would be the cheap and easy way to definitively
answer
] on behalf of Petr Leiman
[petr.lei...@epfl.ch]
Sent: Thursday, December 08, 2011 9:43 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] PHENIX vs REFMAC refinement had me fooled
Dear Tim,
I agree with you completely. The question then becomes why does the automatic
weighting scheme in refmac allow R
My money is on the the wrong test set (as Jonathan Elegheert suggested).
I have seen this several times with newbies, when the test set is
created by phenix. It does it the xplor-way. When it comes to the free
set, refmac defaults to 0, phenix tries to be intelligent (i.e. if 1/0
it uses 1, if
Check your Rfree flag. Phenix and refmac may use different flag. Have a look
into log file. If percentage of Rfree reflections is 95% then flags need to be
swapped.
Garib
On 9 Dec 2011, at 02:50, Mark J van Raaij wrote:
are you sure that you are using the original input intensities for the
24 matches
Mail list logo
