Hi Pavel, I have inherited a refinement project. I was not satisfied with the previous choice of TLS groups. I used TLSMD to determine a new set of TLS domains. Can I just proceed or should I do anything special to the starting PDB to "erase" any influence of the previous choice of TLS groups. Thanks, Scott On May 14, 2010, at 12:28 PM, Pavel Afonine wrote:

Hi Scott,

...

Are there any considerations to changing TLS groups mid refinement?

what you mean?

Sometime soon there will be a tool to identify TLS groups automatically so you don't need to run TLSMD. May be later on we make it run automatically as part of refinement so you just say "I want to do TLS refinement" and the rest will be done for you automatically.

Pavel.

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

Hi, I'm getting ready to deposit some models and they have different FOBS cutoffs. I have been running PHENIX 1.6.1 (336) with the bare bones inputs. I am wondering why there is an FOBS cutoff by default, and how that cutoff is determined? Thanks, -bob

On Fri, 2010-05-14 at 15:35 -0700, Pavel Afonine wrote:

phenix.refine does not use any data cutoff for refinement.

So was the Fo>0 hard-wired cutoff removed? I don't have the latest version so I can't check myself. -- "I'd sacrifice myself, but I'm too good at whistling." Julian, King of Lemurs

This has been discussed before. For a start look at French and Wilson (French G.S. and Wilson K.S. Acta. Cryst. (1978), A34, 517.) Fobs < 0 is not possible, but Fobs = 0 clearly conveys some information (i.e. the reflection is weak). Simply deleting the data is the worst case scenario where you remove any information content on that reflection during refinement. I'm surprised that this would even need further exposition, especially in light of the community tendency to use higher outer-shell Rsymms (50-60%) where a significant proportion of the data would be expected to be weak and therefore subject to risk of arbitrary cutoff by phenix.refine. If I/sigI = 2 (a not uncommon outer shell criterion) then a decent proportion of the data might have I<0, and this data is really there and weak and not the imagination of the processing program. Does phenix.refine enforce an I<=0 cutoff too ? It certainly behaves as if it does. As it stands the best way to get around this undesirable feature of phenix.refine is to use CCP4's TRUNCATE program (with "TRUNCATE YES") which makes much of the weak data small but positive. You still have to tell phenix.refine not to use Imean and SigImean (it will use those if it can find them) and use F instead. Again, include F=0 data. F<0 should probably immediately terminate program execution, since it infers a data content error. Phil Jeffrey Princeton Pavel Afonine wrote:

Hi Ed,

I agree I was too generous in my statement and you promptly caught it, thanks!

phenix.refine does catch and deal with clearly nonsensical situations, like having Fobs<=0 in refinement. So, saying "phenix.refine does not use any data cutoff for refinement" was not precise, indeed. In addition, phenix.refine automatically removes Fobs outliers based on R.Read paper.

I don't see much sense having a term (0-Fcalc)**2 in least-squares target or equivalent one in ML target. Implementing an intensity based ML target function (or corresponding LS) would allow using Iobs<=0, but this is not done yet, and this is a different story - your original question below was about Fo (Fobs).

Do you have rock solid evidence that substituting missing (unmeasured) Fobs with 0 would be better than just using actual set (Fobs>0) in refinement? Or did I miss any relevant paper on this matter? I would appreciate if you point me out. Unless I see a clear evidence that this would improve things I wouldn't waste time on implementing it. Unfortunately I don't have time right now for experimenting with this myself.

Thanks! Pavel.

On 5/17/10 6:52 AM, Ed Pozharski wrote:

...

On Fri, 2010-05-14 at 15:35 -0700, Pavel Afonine wrote:

...

phenix.refine does not use any data cutoff for refinement.

So was the Fo>0 hard-wired cutoff removed? I don't have the latest version so I can't check myself.

------------------------------------------------------------------------

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

Dear Phil,

This has been discussed before. For a start look at French and Wilson (French G.S. and Wilson K.S. Acta. Cryst. (1978), A34, 517.)

do they demonstrate the benefits of using these data in refinement (see below)? Well, I guess I need to re-read it again.

Fobs < 0 is not possible, but Fobs = 0 clearly conveys some information (i.e. the reflection is weak). Simply deleting the data is the worst case scenario where you remove any information content on that reflection during refinement. I'm surprised that this would even need further exposition, especially in light of the community tendency to use higher outer-shell Rsymms (50-60%) where a significant proportion of the data would be expected to be weak and therefore subject to risk of arbitrary cutoff by phenix.refine. If I/sigI = 2 (a not uncommon outer shell criterion) then a decent proportion of the data might have I<0, and this data is really there and weak and not the imagination of the processing program.

I'm all with you: yes, more data is better. Although, I repeat my original question: Did anyone demonstrate that: "refinement with Fobs=0" vs "refinement with Fobs>0" results in : - noticeably better map, so you can find more details, explain more features, - noticeably better model, - anything else visibly better ? If so then I agree it is worth spending time on implementing it. However, if it's just theoretically/esthetically nice to have it (as many other things, like better than Flat bulk solvent model), but the benefits are not really clear - then I would still have it in my todo list (since it's good in general) but with much lower priority. Yes, treating properly negatives and zeros is theoretically good. There is even a paper with myself being a co-author that touches on it. But for practical considerations it's all about the ratio "time invested into implementing it vs benefits obtained as result".

Does phenix.refine enforce an I<=0 cutoff too ? It certainly behaves as if it does.

phenix.refine does not have intensity based X-ray refinement targets and therefore phenix.refine does not use intensities in refinement. Although it accepts input reflection files with intensities which it then converts to amplitudes for all subsequent purposes. Pavel.

On Mon, 2010-05-17 at 17:37 -0400, Phil Jeffrey wrote:

Demonstrate that the way that phenix.refine, as currently implemented, inappropriately throws away weak data is never potentially deleterious to the quality of a protein structure model.

Phil, I have always used denzo/scalepack, and then scalepack2mtz to convert .sca file to .mtz file. So my data is always processed according to French&Wilson. Now from what you are saying I understand that there is some possibility to get into using non-truncated data with phenix? And not only that, it seems to be the default? I suspect that French&Wilson statistics is actually applied by phenix internally if the supplied mtz-file only has intensities. If that is not the case, the problem is more serious than I thought. Otherwise it would take deliberate user effort to get into trouble, since TRUNCATE=YES is the default of the corresponding CCP4 program. Ed. -- "I'd jump in myself, if I weren't so good at whistling." Julian, King of Lemurs

As far as I remember from my early encounters with Denzo and Scalepack during my visit to Yale University in the beginning of 90's (Alan Friedman, if you are listening, thank you for that) Scalepack already is doing sort of "tinkering" and French&Wilson statistics known in other places that claim priority as Haiker statistics, is not necessary. However maybe I am wrong, and input from Otwinowsky or/and Minor may clarify situation. FF Dr Felix Frolow Professor of Structural Biology and Biotechnology Department of Molecular Microbiology and Biotechnology Tel Aviv University 69978, Israel Acta Crystallographica D, co-editor e-mail: [email protected] Tel: ++972 3640 8723 Fax: ++972 3640 9407 Cellular: ++972 547 459 608 On May 18, 2010, at 01:35 , Nathaniel Echols wrote:

On Mon, May 17, 2010 at 3:18 PM, Ed Pozharski wrote: I have always used denzo/scalepack, and then scalepack2mtz to convert .sca file to .mtz file. So my data is always processed according to French&Wilson.

Now from what you are saying I understand that there is some possibility to get into using non-truncated data with phenix? And not only that, it seems to be the default?

FYI, AutoSol, AutoMR, and Phaser all accept scalepack files as input (or d*TREK or XDS, I think), and generate MTZ files as output, so if a user jumps directly from HKL2000 to Phenix, it would be very easy to skip the French&Wilson step. The need to run an extra conversion step in a different suite is not going to be obvious to grad students (and many if not most postdocs).

We've discussed implementing the French&Wilson protocol in CCTBX, but I don't know how much work that is (since I still don't know what it actually does after reading this entire discussion).

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

I doubt this. Scalepack outputs intensities, and the negative ones stay negative. On Tue, 2010-05-18 at 08:44 +0300, Felix Frolow wrote:

Scalepack already is doing sort of "tinkering" and French&Wilson statistics -- "I'd jump in myself, if I weren't so good at whistling." Julian, King of Lemurs

Now from what you are saying I understand that there is some possibility to get into using non-truncated data with phenix?  And not only that, it seems to be the default?

You make it sound like it is a bad thing. The effect of restraint weights (ADP, geometry) has most likely a much bigger impact on the final structure then a small fraction of smallish intensities (*) The French and Wilson procedure does circumvent issues with negative intensities, but depends on some prior knowledge of the intensity distribution and uses this to estimate the 'error free amplitude'. It all sounds nice, but it is not without trouble. If one has pseudo translational symmetry for instance, the basic wilson prior isn't valid. I agree at that smallish intensities are useful (if not essential in that case, depending on the degree of the PTS), but a bayesian update with an incorrect prior might even be worse. Also, why limit oneself to updating negative intensities? This is a fairly arbitrary decision rule. Also, how does one update? Do we update to the most likely posterior intensity or to the most likely posterior amplitude? These need not be the same. I fully agree with Pavel that a solution should be pursued and I also agree that the effort/payoff ratio should be used for ranking purposes. There is a intensity massaging option available in phenix, it is not default, well hidden and not for the faint of heart for reason stated above. Cheers, Peter (*): when the fraction is not small, but fairly sizeable due to pseudo translational symmetry, I definitely wouldn't want to have a French and Wilson procedure let loose on my intensities, but an ML intensity target that can deal with this kind of data is the only solution.

I suspect that French&Wilson statistics is actually applied by phenix internally if the supplied mtz-file only has intensities.  If that is not the case, the problem is more serious than I thought.  Otherwise it would take deliberate user effort to get into trouble, since TRUNCATE=YES is the default of the corresponding CCP4 program.

Ed.

-- "I'd jump in myself, if I weren't so good at whistling."                               Julian, King of Lemurs

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

-- ----------------------------------------------------------------- P.H. Zwart Beamline Scientist Berkeley Center for Structural Biology Lawrence Berkeley National Laboratories 1 Cyclotron Road, Berkeley, CA-94703, USA Cell: 510 289 9246 BCSB: http://bcsb.als.lbl.gov PHENIX: http://www.phenix-online.org CCTBX: http://cctbx.sf.net -----------------------------------------------------------------

The philosophical arguments are fine, but is Pavel not justified in asking for real cases where it matters? It's not like he hasn't spent time thinking about it, and it's not like the whole phenix community isn't sitting in his ear about their own favourite missing fix. I suppose what comes to mind is a case with hectic pseudotranslation causing half the reflections to be systematically almost but not quite zero. But then again, I understand that even if you don't toss the weak ones out, current algorithms don't deal with this well anyway, so it needs special treatment (for now: refine in smaller cell, then rigid-body refine in super-cell). phx. On 18/05/2010 18:33, Ed Pozharski wrote:

On Mon, 2010-05-17 at 16:20 -0700, Peter Zwart wrote:

...

You make it sound like it is a bad thing. The effect of restraint weights (ADP, geometry) has most likely a much bigger impact on the final structure then a small fraction of smallish intensities (*)

Peter,

I think discarding data has to be justified. Two points:

1. The fraction of negative intensities is not necessarily small. It depends on resolution cutoff (and you make an excellent point about PTS), but looking at scalepack log-files I can tell that in my hands the fraction is often 10% or more (DISCLAIMER: I belong to I/sigma=1 resolution cutoff cult).

2. Just because these reflections are weak does not mean that they are insignificant. Their contribution to the maps may be small (now I fear another round of "fill-in missing Fobs with Fc for map calculation" discussion), but keeping Fc close to zero for these reflections during refinement seems to be just as important as to keep Fc close to whatever values the strong reflections have.

The weak reflections are not fundamentally worse than strong(er) reflections in the same resolution range. They are measured with roughly the same precision. Moreover, the practice of setting negative intensities to zero and then ignoring them in refinement discards those that are barely negative and leaves in those that were (quite randomly) barely positive.

You are absolutely right that other factors will have impact on the model. But that does not mean that discarding weak data is justified. Crystallographic refinement is a Rube Goldberg machine, and all the components should be as good as we can make them. Perhaps there could be something better than French&Wilson, but discarding negative intensity reflections is hardly the solution.

Cheers,

Ed.

PS. Personally I have no stake in this, since I always use truncate.

If by "scaling" you mean scaling unmerged observations together, I don't think it is right that it assumes a unimodal intensity distribution. In refinement I believe the underlying distributions are assumed to be unimodal, but in data reduction scaling there is no such assumption. That scaling just assumes that the experiment (mainly the diffraction geometry) can be parameterised in such a way that reflections close together in reciprocal space and in measurement time have similar and parameterisable scales. This is independent of the intensity distribution. Phil On 19 May 2010, at 08:44, [email protected] wrote:

Frank,

Having had a case of such hectic pseudosymmetry, it turns out that the problem originates already from the scaling that assumes a unimodal intensity distribution. The weak reflections then have their sigmas heavily overestimated and the strong ones overestimated. I had to scale the weak and strong reflections separately and ridig-body refine against the weak ones... Of course this type of problem has little to do with issue of treating negative intensities.

Esko

Quoting "Frank von Delft" :

...

The philosophical arguments are fine, but is Pavel not justified in asking for real cases where it matters? It's not like he hasn't spent time thinking about it, and it's not like the whole phenix community isn't sitting in his ear about their own favourite missing fix.

I suppose what comes to mind is a case with hectic pseudotranslation causing half the reflections to be systematically almost but not quite zero. But then again, I understand that even if you don't toss the weak ones out, current algorithms don't deal with this well anyway, so it needs special treatment (for now: refine in smaller cell, then rigid-body refine in super-cell).

phx.

On 18/05/2010 18:33, Ed Pozharski wrote:

...

On Mon, 2010-05-17 at 16:20 -0700, Peter Zwart wrote:

...

You make it sound like it is a bad thing. The effect of restraint weights (ADP, geometry) has most likely a much bigger impact on the final structure then a small fraction of smallish intensities (*)

Peter,

I think discarding data has to be justified. Two points:

1. The fraction of negative intensities is not necessarily small. It depends on resolution cutoff (and you make an excellent point about PTS), but looking at scalepack log-files I can tell that in my hands the fraction is often 10% or more (DISCLAIMER: I belong to I/sigma=1 resolution cutoff cult).

2. Just because these reflections are weak does not mean that they are insignificant. Their contribution to the maps may be small (now I fear another round of "fill-in missing Fobs with Fc for map calculation" discussion), but keeping Fc close to zero for these reflections during refinement seems to be just as important as to keep Fc close to whatever values the strong reflections have.

The weak reflections are not fundamentally worse than strong(er) reflections in the same resolution range. They are measured with roughly the same precision. Moreover, the practice of setting negative intensities to zero and then ignoring them in refinement discards those that are barely negative and leaves in those that were (quite randomly) barely positive.

You are absolutely right that other factors will have impact on the model. But that does not mean that discarding weak data is justified. Crystallographic refinement is a Rube Goldberg machine, and all the components should be as good as we can make them. Perhaps there could be something better than French&Wilson, but discarding negative intensity reflections is hardly the solution.

Cheers,

Ed.

PS. Personally I have no stake in this, since I always use truncate.

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

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

Dear Phil,

Can we turn the argument on its head ?

well, it depends what you call "head" -:)

Short version:

phenix.refine throws out 2896 reflections of 48895, including 11% of the data in the outermost shell, compared to using TRUNCATE to prep my data. Using the common data subset the structure has a decreased R-free of 0.8% if you refine against the truncate=yes PDB file with the common subset of data.

0.8% at a 24% R-free (24.0 vs 24.8) is pretty significant IMHO.

You cannot compare the R-factors that were computed using different sets of reflections. Therefore the above comparison is not valid, obviously. Same applies to your "Longer version". Let's compare apples with apples. Comparing R-factors in this case does not tell that one refinement is better or worse than the other one. It just doesn't tell anything because the R-factor is not a good measure when you deal with two different datasets (datasets containing different amount of reflections). Pavel.

You cannot compare the R-factors that were computed using different sets of reflections. Therefore the above comparison is not valid, obviously. Same applies to your "Longer version". Let's compare apples with apples.

Read the example. It's the same set of reflections. In particular I did that because it's the same set of F's which is not very easy to get to (phenix.refine's reflection utilities don't let me output F if I do a <= truncation on intensity). Specifically: default behavior of Phenix from the mtz is to take Imean, throw away anything with Imean < 0 and convert to F. That mtz file contained F's out of CCP4's TRUNCATE, but all the data. phenix.refine throws that data away internally. So I have three selection methods: 1. TRUNCATE F data which I have to force phenix.refine to use via labels='F,SIGF' 2. F data that phenix.refine converts from Imean 3. A subset of #1 reduced by the selection criteria used in #2 So I take a PDB file refined against option #1 and compare to #3. This contains all the Free R reflections that #2 has but since TRUNCATE modifies the F's. That's about as fair a comparison as I can find: a PDB file refined against #2 and compared to #2 vs a PDB file refined against #1 and compared to #3. The only difference between #1 and #3 is that #1 contains F's with Imean < 0, altered via TRUNCATE.

Comparing R-factors in this case does not tell that one refinement is better or worse than the other one. It just doesn't tell anything because the R-factor is not a good measure when you deal with two different datasets (datasets containing different amount of reflections).

This would mean that the whole thing is inherently untestable because of phenix.refine's rejection criteria - there will always be a difference in data count because of that. Propose a better experiment. Phil

Dear Phil, on a further thought about your "Longer version":

Default behavior yields: Final: r_work = 0.1898 r_free = 0.2479 bonds = 0.007 angles = 1.114 (...) Truncate=yes data yields: Final: r_work = 0.1932 r_free = 0.2473 bonds = 0.007 angles = 1.113

these Rfree-factor results above seem "identical" to me (we can compare them since they were the same for both refinements). Indeed, 0.006% difference - well, this is close to FFT vs direct summation impact -:) Also, see one of my previous posts about possible deviations in R-factors within similar refinement runs. The context was somewhat different but the basic idea stands. Pavel.

Pavel Afonine wrote:

Do you have rock solid evidence that substituting missing (unmeasured) Fobs with 0 would be better than just using actual set (Fobs>0) in refinement? Phil Jeffrey wrote: Fobs = 0 clearly conveys some information (i.e. the reflection is weak). Simply deleting the data is the worst case scenario

The problem seems to be that phenix is using Fobs=0 as a "missing number flag" which precludes its use as a valid measurement. I second the truncate advice, not actually truncating the reflections at zero but histogram-shifting them above zero (French & Wilson). Even without the French & Wilson, the number of refelection that are precisely 0.00000 must be rather small. However if all negative intensities are set to zero there could be a lot, and it might still be good to refine against them, since they must have been pretty weak. Any change which increases their calculated value should be penalized relative to one that decreases it Ed

The person(s) in charge of cctbx can give more specific answer, but I suspect this is not the case. While the main format is mtz (and thus NaN is used to specify missing reflections), it appears to me from a quick look at mmtbx module that internally missing reflections are exactly that - missing from corresponding python data structures.

That's true, but the whole story is slightly more complicated. Reflections with Fobs=0 are ignored at the mtz reading stage if Sigma=0 or Sigma=NaN.

On Mon, 2010-05-17 at 12:49 -0400, Edward A. Berry wrote:

...

The problem seems to be that phenix is using Fobs=0 as a "missing number flag" which precludes its use as a valid measurement.

I think we could fairly easily change phenix.refine to use Fobs=0 if Sigma > 0. I'll add that to the low-priority to-do list (since there's the truncate workaround). Ralf

On Mon, 2010-05-17 at 08:47 -0700, Pavel Afonine wrote:

Do you have rock solid evidence that substituting missing (unmeasured) Fobs with 0 would be better than just using actual set (Fobs>0) in refinement? Or did I miss any relevant paper on this matter? I would appreciate if you point me out. Unless I see a clear evidence that this would improve things I wouldn't waste time on implementing it. Unfortunately I don't have time right now for experimenting with this myself.

Pavel, I don't think anyone (certainly not me) have ever suggested to replace *missing* reflections with zeros. On both occasions (now and last December) the issue was the Fobs=0 reflections introduced by I->F conversion of negative intensities. Ed. -- "I'd jump in myself, if I weren't so good at whistling." Julian, King of Lemurs