*** For details on how to be removed from this list visit the *** *** CCP4 home page http://www.ccp4.ac.uk ***
The behaviour of step 3 (sortmtz) happens because the cell dimensions are deemed to be a property of the crystal rather than the dataset. You have the same crystal, so they are forced to have the same cell dimensions. This is indeed an over-simplification. But it probably doesn't matter since, as Phil says, Scala uses the batch cell dimensions. Use "mtzdmp foo.mtz -b" to view these (buried in the batch headers). Cheers Martyn On Wed, 2006-09-20 at 13:09 +0100, P.R. Evans wrote: > *** For details on how to be removed from this list visit the *** > *** CCP4 home page http://www.ccp4.ac.uk *** > > > I don't understand all of this,but the MTZ files does contain the cells in > the Batch headers, and Scala uses these as the master cell dimensions. At > present there is no easy way to change these :-( > > However, if you are merging these files from the same crystal, you are > assuming the unit cell is constant, and the programs have no easy way to > determine which is best (which is why Scala takes an average). > > If you have a better idea of the cell, you can change it later with eg CAD > > Determining accurate cell dimensions is not trivial, and will be less > accurate at low resolution (and also wrong if your wavelength is wrong) > > Phil > > > Hi all, > > > > We have found a puzzle about cell dimensions. Not really a problem, just > > something a bit confusing. This is our scenario: > > > > 1. We collected data in two passes (high and low resolution) > > 2. The high and low resolution passes were integrated with mosflm, > > producing two mtz files. The cell dimensions as output by mosflm and > > read from these mtz files are respectively: > > > > HR: 42.6287 191.4204 71.9418 90.0000 90.0000 90.0000 > > LR: 42.6423 191.1283 71.9388 90.0000 90.0000 90.0000 > > > > (OK, we could have forced the LR pass to have the same cell, but somehow > > it happened to be refined) > > > > 3. We put them together using sortmtz. The header of the resulting mtz > > file says: > > > > 8<-------------------------------------------------------------->8 > > * Title: > > > > . > > > > * Base dataset: > > > > 0 HKL_base > > HKL_base > > HKL_base > > > > * Number of Datasets = 2 > > > > * Dataset ID, project/crystal/dataset names, cell dimensions, > > wavelength: > > > > 1 Mer > > p67B1 > > natHR180 > > 42.6423 191.1283 71.9388 90.0000 90.0000 90.0000 > > 0.93400 > > 2 Mer > > p67B1 > > natLR180 > > 42.6423 191.1283 71.9388 90.0000 90.0000 90.0000 > > 0.93400 > > > > * Number of Columns = 18 > > > > * Number of Reflections = 280753 > > > > * Missing value set to NaN in input mtz file > > > > * Number of Batches = 360 > > > > * HISTORY for current MTZ file : > > > > From SORTMTZ 18/ 9/2006 11:01:19 using keys: H K L M/ISYM BATCH > > > > From MOSFLM run on 18/ 9/06 > > > > > > * Column Labels : > > > > H K L M/ISYM BATCH I SIGI IPR SIGIPR FRACTIONCALC XDET YDET ROT WIDTH > > LP MPART FLAG BGPKRATIOS > > > > * Column Types : > > > > H H H Y B J Q J Q R R R R R R I I R > > > > * Associated datasets : > > > > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > > > > * Cell Dimensions : (obsolete - refer to dataset cell dimensions > > above) > > > > 42.6423 191.1283 71.9388 90.0000 90.0000 90.0000 > > > > * Resolution Range : > > > > 0.00011 0.25071 ( 95.783 - 1.997 A ) > > - ---------------------------------------------------------------->8 > > > > So, first problem/feature/bug: sortmtz assigns to the first dataset > > (HR) the cell dimensions of the second one (LR). > > > > 4. We then scaled together with scala these data, producing a new > > combined dataset. When scala reads the mtz from the previous step it > > outputs these warnings: > > > > 8<---------------------------------------------------------------- > > WARNING: output dataset Mer/p67B1/native180 contains input datasets > > with different Project Names > > > > WARNING: output dataset Mer/p67B1/native180 contains input datasets > > with different Crystal Names > > > > ===== Dataset: Mer/p67B1/native180 > > Run(s): 1 2 > > > > * Wavelength and cell extracted from Batch headers, with rms variation: > > * Wavelength: 0.934000 Cell: 42.636 191.274 71.940 90.000 > > 90.000 90.000 > > * rms 0.000000 rms 0.000 0.139 0.000 0.000 > > 0.000 0.000 > > Wavelength: 0.934000 Cell: 42.636 191.274 71.940 90.000 > > 90.000 90.000 > > - ---------------------------------------------------------------->8 > > > > I don't understand the warnings: it is precisely the Project and > > Crystal names which are identical, only the output dataset (native180) > > being different from the input ones (natHR180 and natLR180). I also > > notice that the cell shown here is an average from the HR and LR > > datasets. This cell is also the one obtained in the output mtz from > > scala. Thus, I deduce that the HR cell is somehow present in the mtz > > that comes from sortmtz, though I cannot see it in its header. > > > > All this may be good and well, but I find it a bit confusing, and > > that's why I report it. > > > > Cheers, > > > > > > Miguel > > - -- > > Miguel Ortiz Lombardía > > Centro de Investigaciones Oncológicas > > C/ Melchor Fernández Almagro, 3 > > 28029 Madrid, Spain > > Tel. +34 912 246 900 > > Fax. +34 912 246 976 > > email: [EMAIL PROTECTED] > > www: http://www.ysbl.york.ac.uk/~mol/ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Je suis de la mauvaise herbe, > > Braves gens, braves gens, > > Je pousse en liberté > > Dans les jardins mal fréquentés! > > Georges Brassens > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.1 (GNU/Linux) > > > > iD8DBQFFESYEF6oOrDvhbQIRAmtvAJ98nr6OjtXoqmNkEqhyp/Vk1fw9jgCdGqbW > > jEyduDUCEWviHBwDMIk7LiY= > > =JAw5 > > -----END PGP SIGNATURE----- > > >
