Dear Pavel, find attached the requested output. CRYST card from refined pdb file CRYST1 175.170 67.236 119.246 90.00 121.42 90.00 C 1 2 1 phenix.mtz.maps test.map > Title: None Space group symbol from file: C2 Space group number from file: 5 Space group from matrices: C 1 2 1 (No. 5) Point group symbol from file: 2 Number of crystals: 2 Number of Miller indices: 40081 Resolution range: 101.452 2.52205 History: Crystal 1: Name: HKL_base Project: HKL_base Id: 0 Unit cell: (175.093, 67.251, 119.05, 90, 121.55, 90) Number of datasets: 1 Dataset 1: Name: HKL_base Id: 0 Wavelength: 0 Number of columns: 0 Crystal 2: Name: crystal Project: project Id: 2 Unit cell: (175.093, 67.251, 119.05, 90, 121.55, 90) Number of datasets: 1 Dataset 1: Name: dataset Id: 1 Wavelength: 1 Number of columns: 13 I made sure that this file is indeed the one being read by the .def file. best wishes Michael On 04/20/2011 08:36 PM, Pavel Afonine wrote:

Hi Michael,

phenix.refine should take crystal symmetry from data file if there is a choice between PDB file and data file.

Did you mean phenix.mtz.dump? Can you send the output of

phenix.mtz.dump data.mtz

command, and CRYST1 record from PDB file as Nat asked?

Pavel.

On 4/20/11 3:36 PM, Michael Hothorn wrote:

...

Dear all,

I am sure there is a simple explanation for this, but I cannot find a solution. I am reading in an .mtz file in phenix.refine. mtzdump reports the following unit cell constants on the file test.mtz itself:

175.0930 67.2510 119.0500 90.0000 121.5500 90.0000

The refined .pdb file and .maps report however a slightly different unit cell, as does the logfile

...

snip Miller array info: test.mtz:FP,SIGFP Observation type: xray.amplitude Type of data: double, size=39702 Type of sigmas: double, size=39702 Number of Miller indices: 39702 Anomalous flag: False Unit cell: (175.17, 67.236, 119.246, 90, 121.416, 90)

What am I missing?

Thanks! Michael

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

I found my mistake. The cell parameter definition in the .def file apparently overrules the definition in either the input .mtz or in the input .pdb CRYST1 card. Is that correct like this: .def file definition

.mtz definition > CRYST1 card definition?

best wishes Michael On 04/20/2011 09:35 PM, Pavel Afonine wrote:

Hi Michael,

I'm still confused.. What is .map file?

Are you running refinement as following:

phenix.refine model.pdb data.mtz

?

OK, I got the CRYST1 from model.pdb, now what is the unit cell parameters in data.mtz (you can get it with "phenix.mtz.dump data.mtz")? What is CRYST1 record in PDB file with refined model (model_refine_001.pdb) ?

May be it's easier if you send the relevant inputs (off list) and tell how you arrived to observing different unit cell parameters..

Pavel.

On 4/20/11 9:19 PM, Michael Hothorn wrote:

...

Dear Pavel,

find attached the requested output.

CRYST card from refined pdb file CRYST1 175.170 67.236 119.246 90.00 121.42 90.00 C 1 2 1

phenix.mtz.maps test.map >

Title: None Space group symbol from file: C2 Space group number from file: 5 Space group from matrices: C 1 2 1 (No. 5) Point group symbol from file: 2 Number of crystals: 2 Number of Miller indices: 40081 Resolution range: 101.452 2.52205 History: Crystal 1: Name: HKL_base Project: HKL_base Id: 0 Unit cell: (175.093, 67.251, 119.05, 90, 121.55, 90) Number of datasets: 1 Dataset 1: Name: HKL_base Id: 0 Wavelength: 0 Number of columns: 0 Crystal 2: Name: crystal Project: project Id: 2 Unit cell: (175.093, 67.251, 119.05, 90, 121.55, 90) Number of datasets: 1 Dataset 1: Name: dataset Id: 1 Wavelength: 1 Number of columns: 13

I made sure that this file is indeed the one being read by the .def file.

best wishes Michael

On 04/20/2011 08:36 PM, Pavel Afonine wrote:

...

Hi Michael,

phenix.refine should take crystal symmetry from data file if there is a choice between PDB file and data file.

Did you mean phenix.mtz.dump? Can you send the output of

phenix.mtz.dump data.mtz

command, and CRYST1 record from PDB file as Nat asked?

Pavel.

On 4/20/11 3:36 PM, Michael Hothorn wrote:

...

Dear all,

I am sure there is a simple explanation for this, but I cannot find a solution. I am reading in an .mtz file in phenix.refine. mtzdump reports the following unit cell constants on the file test.mtz itself:

175.0930 67.2510 119.0500 90.0000 121.5500 90.0000

The refined .pdb file and .maps report however a slightly different unit cell, as does the logfile

...

snip Miller array info: test.mtz:FP,SIGFP Observation type: xray.amplitude Type of data: double, size=39702 Type of sigmas: double, size=39702 Number of Miller indices: 39702 Anomalous flag: False Unit cell: (175.17, 67.236, 119.246, 90, 121.416, 90)

What am I missing?

Thanks! Michael

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

On Thu, Apr 21, 2011 at 11:21 AM, Jacob Keller wrote:

Actually, this thread raises an interesting issue: do refinement programs ever refine cell parameters (I think they do not.)

Not as far as I'm aware.

I wonder whether it would make any difference, especially in things like bond lengths? Should be easy enough to include, but I guess the gains might not be so significant? I would imagine, though, that once one had a working model, one could make a histogram of observed bond lengths and their orientations, and scale the cell parameters accordingly to make the bond-length distribution be centered on the ideal lengths. This might perhaps be another source of "missing R"?

I've never used WHATCHECK, but I'm told it does something like you describe, and alerts the user to possibly incorrect cell dimensions. (I'm hoping to add this to the PHENIX validation eventually, but I don't know the math.) Packing analysis can also give similar indications that something is wrong: http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2708028/?tool=pubmed But I think the error needs to be much larger than you're likely to get from processing the data for the refinement to suffer significantly. It definitely doesn't explain the discrepancy in R-factors, since even an excellent protein crystal diffracting to atomic resolution - where there is no doubt as to the unit cell parameters - will still have this problem. -Nat

Hi,

...

Actually, this thread raises an interesting issue: do refinement programs ever refine cell parameters (I think they do not.) Not as far as I'm aware.

definitely not in phenix.refine.

...

I wonder whether it would make any difference, especially in things like bond lengths? Should be easy enough to include, but I guess the gains might not be so significant? I would imagine, though, that once one had a working model, one could make a histogram of observed bond lengths and their orientations, and scale the cell parameters accordingly to make the bond-length distribution be centered on the ideal lengths. This might perhaps be another source of "missing R"? I've never used WHATCHECK, but I'm told it does something like you describe, and alerts the user to possibly incorrect cell dimensions. (I'm hoping to add this to the PHENIX validation eventually, but I don't know the math.)

Not going into discussion whether this would be beneficial or not, from implementation point of view it should be very easy to do: just grid-search scan around each unit cell dimension and angle (that can deviate) in some small interval and score the result by R-factors. I would write a simple Python script that does this (it would be under 50 lines using CCTBX tools) and run through the whole PDB. In parallel one can do a control experiment by faking Fobs (compute from model in some way) and see how small unit cell changes affect the R-factors. A nice project for a summer student -:) Pavel.

Hi Dale,

This would not work because the cell constants are highly correlated with the other parameters in the model. You have to change the cell, refine all the other parameters, and then write down the R value. Many people have become confused by performing the test you describe. It shows a very steep dependency between the R value and the cell constants but the lowest R value is always at the values for the cell the model was refined with. If you perform your grid test and refine at each step you will see the broad minimum.

Dale Tronrud

realizing it, this is why I refixed my reply with "Not going into discussion whether this would be beneficial or not" -:) By suggesting this test I was thinking to catch some gross errors in unit cell parameters (that were probably not compensated by refinement of other parameters). My previous experience with some other similar searches tells me that you can find almost everything in this database. Pavel.

On 04/21/11 11:21, Jacob Keller wrote:

Actually, this thread raises an interesting issue: do refinement programs ever refine cell parameters (I think they do not.) I wonder whether it would make any difference, especially in things like bond lengths? Should be easy enough to include, but I guess the gains might not be so significant? I would imagine, though, that once one had a working model, one could make a histogram of observed bond lengths and their orientations, and scale the cell parameters accordingly to make the bond-length distribution be centered on the ideal lengths. This might perhaps be another source of "missing R"?

Jacob

If you try to refine a model with the cell "constants" allowed to vary you will find that they are not well determined. You can change them by huge amounts and refine the model down to pretty much the same R value. The truth is that there is little in our calculation of the scattering of a crystal that is tied to an absolute scale. The scattering factor is on such a scale but you can inflate all the B values and correct for a cell constant that has become too large. The only thing that ties down the scale are the bond length restraints, and of course you are restraining them. If you inflate your cell constants the bonded atoms will move a little big apart but the rest of the slack will be taken up in the space between the chains. Tight or sloppy packing is the tool to use, but we don't restrain those so they don't help if you want to determine the cell lengths. The location of the spots on the images give a wealth of information about the cell constants leading to very precise values, if you know your wave length and crystal to detector distance. Intensities, not so much. Dale Tronrud

On Thu, Apr 21, 2011 at 11:47 AM, Michael Hothorn wrote:

...

I found my mistake. The cell parameter definition in the .def file apparently overrules the definition in either the input .mtz or in the input .pdb CRYST1 card. Is that correct like this: .def file definition > .mtz definition > CRYST1 card definition?

best wishes Michael

On 04/20/2011 09:35 PM, Pavel Afonine wrote:

...

Hi Michael,

I'm still confused.. What is .map file?

Are you running refinement as following:

phenix.refine model.pdb data.mtz

?

OK, I got the CRYST1 from model.pdb, now what is the unit cell parameters in data.mtz (you can get it with "phenix.mtz.dump data.mtz")? What is CRYST1 record in PDB file with refined model (model_refine_001.pdb) ?

May be it's easier if you send the relevant inputs (off list) and tell how you arrived to observing different unit cell parameters..

Pavel.

On 4/20/11 9:19 PM, Michael Hothorn wrote:

...

Dear Pavel,

find attached the requested output.

CRYST card from refined pdb file CRYST1 175.170 67.236 119.246 90.00 121.42 90.00 C 1 2 1

phenix.mtz.maps test.map >

Title: None Space group symbol from file: C2 Space group number from file: 5 Space group from matrices: C 1 2 1 (No. 5) Point group symbol from file: 2 Number of crystals: 2 Number of Miller indices: 40081 Resolution range: 101.452 2.52205 History: Crystal 1: Name: HKL_base Project: HKL_base Id: 0 Unit cell: (175.093, 67.251, 119.05, 90, 121.55, 90) Number of datasets: 1 Dataset 1: Name: HKL_base Id: 0 Wavelength: 0 Number of columns: 0 Crystal 2: Name: crystal Project: project Id: 2 Unit cell: (175.093, 67.251, 119.05, 90, 121.55, 90) Number of datasets: 1 Dataset 1: Name: dataset Id: 1 Wavelength: 1 Number of columns: 13

I made sure that this file is indeed the one being read by the .def file.

best wishes Michael

On 04/20/2011 08:36 PM, Pavel Afonine wrote:

...

Hi Michael,

phenix.refine should take crystal symmetry from data file if there is a choice between PDB file and data file.

Did you mean phenix.mtz.dump? Can you send the output of

phenix.mtz.dump data.mtz

command, and CRYST1 record from PDB file as Nat asked?

Pavel.

On 4/20/11 3:36 PM, Michael Hothorn wrote:

...

Dear all,

I am sure there is a simple explanation for this, but I cannot find a solution. I am reading in an .mtz file in phenix.refine. mtzdump reports the following unit cell constants on the file test.mtz itself:

175.0930 67.2510 119.0500 90.0000 121.5500 90.0000

The refined .pdb file and .maps report however a slightly different unit cell, as does the logfile

> snip Miller array info: test.mtz:FP,SIGFP Observation type: xray.amplitude Type of data: double, size=39702 Type of sigmas: double, size=39702 Number of Miller indices: 39702 Anomalous flag: False Unit cell: (175.17, 67.236, 119.246, 90, 121.416, 90)

What am I missing?

Thanks! Michael

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

On 04/21/11 12:26, Jacob Keller wrote:

...

The location of the spots on the images give a wealth of information about the cell constants leading to very precise values, if you know your wave length and crystal to detector distance. Intensities, not so much.

I think that there is a fair amount of imprecision here. For example, what is the usual precision of the beamline-defined crystal-detector distance, and of the wavelength? Even 1mm/100mm total distance could have its effect on cell parameters, and I don't think refinement of the distance based on trigonometric distortion has a very sharp minimum, although please correct me if I am wrong (how is the detector distance calibrated, anyway?). Even having an oblong crystal might change the distance by ~0.5mm or so. But this is theoretical, and I think you have much more empirical, real knowledge--what are the levels of precision on these fronts, and how precisely do we know cell parameters from experiment (I thought it was pretty imprecise)?

My understanding of data collection is that the least accurate contributors all lead to scaling errors. This means that the cell angles and ratios of the cell lengths are pretty precise. We are left with an uncertainty in the isotropic scale of the crystal. When I've done detailed comparisons of models from two different crystals (even isomorphous ones) I've superimposed them by a rotation, translation, AND scale to minimize systematic errors. It's not perfect because the bond length restraints ensure that the distortions are not distributed uniformly, but it does reduce the background level of differences. You are worried about the 1% error in cell scale that might result from a measurement error in the data collection set up. I don't see that refining the cell constant along with the other parameters is going to give anything better. The worst case I've see is a model that was refined with A and B set 10% too large (The PDB entry has been obsoleted but I can dig it up if you want.) When I refined the model with the correct cell the R factor dropped by about 3%. Measurable, but 10% is huge and 3%, when in the mid-twenties, is not. What resolution you ask? It depends on which cell constants you believe! Let's just say it was around 2.5 A. This problem was uncovered by a survey of the PDB using a packing analysis check. It stood out as one of the loosest packed models. Dale Tronrud

Jacob _______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb