*** For details on how to be removed from this list visit the *** *** CCP4 home page http://www.ccp4.ac.uk ***
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Phil and Martyn, Thank you very much for your explanations. It is now clear, I didn't know about the batch information, nor about the "-b" option of mtzdmp. I agree that the cell is a property of the crystal, except for the cases where radiation can change it. I see that sortmtz simply forces the crystal to have the cell dimensions of the last mtz that it merges. In our case, I'm almost sure that the "true" cell dimensions are those of the high resolution pass. Integration of the low resolution pass, however, went better when we re-refined the cell. The differences are not big, though. Cheers, Miguel PS: Still a bit confused about the warnings in scala concerning different Project and Crystal names... Martyn Winn wrote: > *** 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----- >> >> >> > > - -- 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) iD8DBQFFEWBNF6oOrDvhbQIRAk7jAJ9WckHSpL6JU8waeSAETVsScE0+eACaArHR 050FORxVzfR6WidUTxnArDE= =z1MM -----END PGP SIGNATURE-----
