Hi Michele,
On Tue, Nov 17, 2009 at 10:28:45PM +0100, Michele Lunelli wrote:
> Clemens Vonrhein wrote:
>
> >
> > SCALA (as far as I know) gets its cell dimensions from the so-called
> > batch header (since each image could have a different cell it averages
> > those). So the problem isn't yet visible in your output - just do
> >
> > % mtzdmp CONVERT/F2MTZCOMBAT_peak.mtz -b
> >
> > and look at the batch header. Most likely COMBAT (if that is what you
> > used guessing from the name) wrote a wrong batch header - it seems to
> > leave it at some default or undefined state which can be fatal further
> > down the line.
> >
>
> f2mtz and combat seem to produce mtz files with the correct cell
> dimension in the header.
Yes - but it is the batch header that is used in SCALA to extract the
cell dimension and not the informaiton in the MTZ header (Phil will
correct me if I'm wrong). This 'batch header' is different from the
normal MTZ file header and a feature of so-called multi-record MTZ
files. You can see if your MTZ file is such a multi-record MTZ file if
the log-file from a CCP4 program metions something about "Number of
batches" (in your case this is 1).
To see the batch header (not just the MTZ file header) you need to run
% mtzdmp your.mtz -b
which gives you one additional block per batch (i.e. in your case a
single block).
> Indeed the file read by sortmtz has the correct cell dimension, as
> reported in the logfile.
That's misleading: the log-files only show MTZ header information and
not the full detail of the batch header(s).
> Also the file opened by scala (CONVERT/SCALAMERGE_peak.mtz in the
> logfile) seems to have the correct cell dimension. The wrong
> dimension appears in the output mtz file
> (CONVERT/SCALAMERGE_peak.mtz1). However I solved the problem by
> simply merging the reflections when processed by xscale. Thanks
> anyway for the suggestions!
If you come from XDS: I have good experience running
% pointless -copy xdsin XDS_ASCII.HKL hklout XDS_ASCII.mtz
and then use that XDS_ASCII.mtz in scala (with your favourite script
or CCP4i or xyz).
Cheers
Clemens
--
***************************************************************
* Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com
*
* Global Phasing Ltd.
* Sheraton House, Castle Park
* Cambridge CB3 0AX, UK
*--------------------------------------------------------------
* BUSTER Development Group (http://www.globalphasing.com)
***************************************************************
|