Hi Pete, A couple of observations with this. I found when doing cell refinement with Mosflm setting a conservative resolution limit *was* very helpful in making sure that the refinement was stable. But then switching back to the full detector area for integration was fine after that. However - and this is a big however, the data analysed for this were typically reasonably high resolution i.e. 3 - 1.6 A.
I've not tried the same thing with a lot of lower resolution data - there are not many people out there making loads of useful 6A data sets public! Best wishes, Graeme On 19 March 2012 22:22, Pete Meyer <pame...@mcw.edu> wrote: > Hi Graeme, > > >> That's interesting. When I looked at this (and I would say I looked >> reasonably carefully) I found it only made a difference in the scaling >> - integrating across the whole area was fine. However, I would expect >> to see a difference, and likely an improvement, in scaling only the >> data you want. It would also give you sensible merging statistics >> which you'll probably want when you come to publish or deposit. > > > I've seen low-resolution datasets where the resolution cutoff had a fairly > significant impact on integration - usually in cell or orientation > refinement. This seemed to make sense, as trying to use large numbers of > spots that weren't really there (and so had essentially undetermined > positions) tended to lead to instabilities in refinement. > > What resolution ranges were you looking at? > > Pete > > >> >> Abd Ghani: if you'd like to rerun the processing at Diamond to a >> chosen resolution limit I will be happy to send some instructions. >> That's probably a good idea. >> >> Best wishes, >> >> Graeme >> >> On 19 March 2012 14:31, Tim Gruene <t...@shelx.uni-ac.gwdg.de> wrote: >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Dear Abd Ghani, >>> >>> The method described by Graeme is how the resolution can be delimited >>> artificially. >>> If you want to get the best from your data, determine the resolution >>> limit of your data e.g. with pointless (I/sigI > 2.0 is a good marker) >>> and reprocess the data to that limit. If you integrate the whole >>> detector area and the outer parts contain only noise, the noise has a >>> negative effect on the real data. >>> >>> Tim >>> >>> On 03/19/12 15:25, Graeme Winter wrote: >>>> >>>> ... presuming of course the automated software got this resolution limit >>>> right. >>>> >>>> If for whatever reason you would like to cut the limit mtzutils will >>>> do this nicely: >>>> >>>> mtzutils hklin blah_free.mtz hklout blah_lower.mtz << eof >>>> resolution 1.8 >>>> eof >>>> >>>> (say) - I am sure there are other ways within the suite to do this. >>>> >>>> Best wishes, >>>> >>>> Graeme >>>> >>>> >>>> On 19 March 2012 14:21, Eleanor Dodson <eleanor.dod...@york.ac.uk> >>>> wrote: >>>>> >>>>> Qs >>>>> >>>>> 1) Why do you want to limit your data? >>>>> >>>>> Most applications allow you to only use a specified sub-set - see GUI >>>>> tasks >>>>> for "resolution limits". >>>>> >>>>> In general you may want to run moleculer replacement or exptl phasing >>>>> at a >>>>> limited resolution, but for refinenement or phase extension it is good >>>>> to >>>>> use the whole range.. >>>>> >>>>> Eleanor >>>>> >>>>> >>>>> On Mar 19 2012, Abd Ghani Abd Aziz wrote: >>>>> >>>>>> hello everyone, >>>>>> >>>>>> I am new in this bulletin board. I would like to know on how to cut my >>>>>> resolution in my datasets that have been processed/produced in diamond >>>>>> light >>>>>> source. In my processed directory, I found there are 3 files >>>>>> (free.mtz, >>>>>> scaled.sca and unmerged.sca). May I know which one can be used to cut >>>>>> my >>>>>> data that was diffracted to 1.5A? Cheers >>>>>> >>>>>> regards >>>>>> Abd Ghani >>>>>> The University of Sheffield >>>>>> >>>>> -- >>>>> Professor Eleanor Dodson >>>>> YSNL, Dept of Chemistry >>>>> University of York >>>>> Heslington YO10 5YW >>>>> tel: 00 44 1904 328259 >>>>> Fax: 00 44 1904 328266 >>> >>> - -- >>> - -- >>> Dr Tim Gruene >>> Institut fuer anorganische Chemie >>> Tammannstr. 4 >>> D-37077 Goettingen >>> >>> GPG Key ID = A46BEE1A >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.12 (GNU/Linux) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>> >>> iD8DBQFPZ0MfUxlJ7aRr7hoRAgysAKDwEYp5QK8l1ggcjNWeGDqfHHfMnQCfRVrZ >>> 9kR9Pkg0bkZsHFQDSsI5QFU= >>> =mn05 >>> -----END PGP SIGNATURE----- > >
