Dear Kay, Thanks for the quick reply. Let me answer your questions: a) Recycling of geometry parameters is certainly worth trying, although in our experience it rarely yields large improvements. Obviously, XDS used to do a pretty good job in default mode. In the latest version, however, since refinement of the detector distance is disabled by default, recycling cannot be expected to (and indeed does not) help. b) The data I mentioned have been collected at ESRF ID29 and processed using the XDS.INP file they provided, with slight modifications unrelated to geometry refinement. c) Yes, defining REFINE(IDXREF) to include POSITION does not solve the problem. It seems that refinement of the distance is still strongly restrained, so there must have been changes to the code other than removal of POSITION refinement from the REFINE(IDXREF) defaults. Consequently, parameter recycling does not help much even with POSITION refinement re-enabled in IDXREF.
The bottom line is that there appears to be no obvious way to restore the previous behaviour by just changing parameters (but of course I may have missed something). I think such an option is urgently required. The most worrisome aspect about this issue, in my opinion, is that it may go unnoticed in many cases. The way it stands now, people affected by inaccuracies in detector distance (or maybe other parameters) may be misled to choose cut-offs for integration at much too high dmin, discarding valuable data. I am happy to provide data needed for investigation. Let's discuss this part off-list. Best regards Oliver ================================================ PD Dr. Oliver H. Weiergräber Institute of Complex Systems ICS-6: Structural Biochemistry Tel.: +49 2461 61-2028 Fax: +49 2461 61-9540 ================================================ ________________________________________ From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Kay Diederichs [kay.diederi...@uni-konstanz.de] Sent: Tuesday, January 23, 2018 9:16 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Issues with latest XDS (20171218) Dear Oliver, sorry for the trouble! A default should be correct in the majority of situations, but it's impossible to have it work for _all_ situations. The XDS default for REFINE(IDXREF) was changed (i.e. POSITION was removed) to improve the indexing for weak and lousy data, _and_ because the distance values from the header are nowadays almost always accurate. For data with very high resolution such as yours, and significantly wrong distance, this means that at high resolution in particular this default will lead to worse data. generate_XDS.INP (in XDSwiki) and (I think) autoPROC and xia2 explicitly include POSITION in the REFINE(IDXREF), i.e. override the default. Where did you get XDS.INP from? Some comments: a) this is why I recommend, for data sets that may be important, to always do one cycle of optimization, i.e. after CORRECT, "mv GXPARM.XDS XPARM.XDS", change XDS.INP to have the correct high-resolution cutoff (cutting after the last shell which still has a "*" in the CC1/2 column), adjust the FRIEDEL'S_LAW= setting, and run JOB=INTEGRATE CORRECT. In your case this would make the refined distance available to INTEGRATE, and should result in very good data. b) at which beamline did you collect the data? Such a high difference between refined distance and distance from header is unusual, and should be reported to (and fixed by) the beamline staff. c) for this beamline at least, one should use REFINE(IDXREF)=CELL BEAM ORIENTATION AXIS POSITION . I understand that you tried this and it didn't work? Maybe there is something else wrong then, e.g. another line later in XDS.INP resetting REFINE(IDXREF) to something else. If you cannot find the reason why including POSITiON into REFINE(IDXREF) does not help, pls send me enough data to reproduce the problem. best wishes, Kay On Tue, 23 Jan 2018 14:31:09 +0000, "Weiergräber, Oliver H." <o.h.weiergrae...@fz-juelich.de> wrote: >Dear all, > >After upgrading XDS from build date 20170601 to 20171218, I am experiencing >severe degradation of apparent data quality reported by CORRECT for certain >data sets. Following first indications of issues with a slightly problematic >candidate, I went back to a previously very well-behaved test case with >diffraction extending beyond 1.1 A. Using the same input with both program >versions, statistics are not too different out to approx. 1.6 A, but become >more and more divergent in outer shells. These are the values for the >highest-resolution shell (1.10--1.16 A): > >20170601: I/sigI = 1.80; Rmeas = 59.9 %; CC(1/2) = 82.0 % >20171218: I/sigI = 0.14; Rmeas = 506.4 %; CC(1/2) = 5.8 % > >The refined cell constants are unreasonably different as well. Obviously, >something is going awfully wrong here, presumably related to errors in >geometry parameters (which are expected to become increasingly detrimental >with decreasing dmin). As it turns out, geometry refinement behaves >differently in the latest version of XDS: most notably, IDXREF no longer >refines the detector distance by default. This is significant in this case, as >in version 20170601 the distance would shift by as much as 1.3 mm, resulting >in successful integration and scaling. Unfortunately, re-adding POSITION >refinement into REFINE(IDXREF) does not help, and even having it in all >refinement scopes (IDXREF, INTEGRATE, CORRECT) only yields a limited >improvement of CORRECT statistics. >It is worth noting that examination of a dataset from an unrelated crystal >(dmin = 1.4 A) did not reveal such enormous differences -- in this case, >however, the shift in detector distance applied in the old version of XDS was >quite small (0.2 mm), which, together with the lower resolution, explains the >absence of large discrepancies. > >To sum up, I suspect that, due to recent changes to the XDS code, the >refinement of geometry parameters is now overly restrained, resulting in >drastic problems in cases where the detector distance is not as precise as >desirable (and even more so at very high resolution). For such datasets, the >new version appears to be essentially unusable (at least within the parameter >space I have tested), and even in modest cases may often be inferior to the >previous one. Is there an option to revert to the former behaviour? > >Best regards >Oliver > >================================================ > PD Dr. Oliver H. Weiergr�ber > Institute of Complex Systems > ICS-6: Structural Biochemistry > Tel.: +49 2461 61-2028 > Fax: +49 2461 61-9540 >================================================ > > > > >------------------------------------------------------------------------------------------------ >------------------------------------------------------------------------------------------------ >Forschungszentrum Juelich GmbH >52425 Juelich >Sitz der Gesellschaft: Juelich >Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 >Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher >Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), >Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, >Prof. Dr. Sebastian M. Schmidt >------------------------------------------------------------------------------------------------ >------------------------------------------------------------------------------------------------
