TIm,
> As far as I can tell the ccp4 utilities for doing so extend the
> resolution from A to match the resolution of B which results in mtzdmp
> displaying the wrong resolution of the data which I find very annoying.
I wasn't aware that mtzdump "displays the wrong resolution": I thought
I had fixed that problem years ago. Are you looking in the right
place in the output? The resolution values on the RESO keyword in the
header (use 'less' or a text editor on the MTZ file to see it, the
'header' is actually right at the end of the file - so it's really a
'trailer'!) refers to the resolution limits (d_max and d_min)
calculated from the hkl values in the file, regardless of the contents
of the data columns. That has always been the case: mtzdump is only
reporting what's in the file header/trailer. Then the table printed
out by mtzdump (see below for example) shows the d_max & d_min for
data in each column excluding NaNs (undefined values). These could
well be different from the d_max & d_min in the header/trailer and
indeed from each other.
So in the example below the d_max & d_min for the hkl's is 64.829 &
1.4, and the values for each individual column, some of which are
different from these, are shown in the table.
Are you seeing something different from this, if so there's a bug
somewhere that we should fix?
Cheers
-- Ian
* Resolution Range :
0.00024 0.51020 ( 64.829 - 1.400 A )
* Sort Order :
1 2 3 0 0
* Space group = 'P 21 21 21' (number 19)
OVERALL FILE STATISTICS for resolution range 0.000 - 0.510
=======================
Col Sort Min Max Num % Mean Mean Resolution
Type Column
num order Missing complete abs. Low High
label
1 ASC 0 39 0 100.00 14.8 14.8 64.83 1.40 H H
2 NONE 0 44 0 100.00 16.5 16.5 64.83 1.40 H K
3 NONE 0 92 0 100.00 34.6 34.6 64.83 1.40 H L
4 NONE 0.0 19.0 0 100.00 9.51 9.51 64.83 1.40
I FreeR_flag
5 NONE 0.0 311.5 62138 31.18 48.84 48.84 19.96 2.00 F F
6 NONE 0.0 14.6 62138 31.18 2.11 2.11 19.96 2.00 Q SIGF
