Dear Leo,
What seems to have happened is that an existing thread where fine
phi (actually: omega!) slicing was discussed, among many other things,
digressed into a discussion of data collection protocols using more
than one instrumental setting (either using a 2-theta motion of the
detector, or a chi reorientation of the crystal). Briefly, my two
cents on that topic: a 2-theta movement may help use different pixels
on the detector, and could be valuable in filling the wide horizontal
gaps on a Pilatus or Eiger, but it will leave the cusp in the same
place and therefore will not fill it. Reorienting the crystal, on the
other hand, can help cure all the known ills of single-sweep datasets
(gaps and cusp in particular).
On the matter of multi-orientation data collection, the idea and
the practice go back (at least, in my memory) to Alan Wonacott, the
co-creator of the Arndt-Wonacott rotation camera in the early 1970's.
It was all done with gonio arcs. As each crystal had to be aligned
manually in order to continue data collection where the previous one
had left off, these arcs were in constant use, and there was always an
extra cusp-filling collection at the end. Nowadays data collection has
speeded up so much, and has become so dominated by automation, that
multi-axis goniometry has been sidestepped because using it properly
would have had to involve non-automated steps that are difficult to
standardise (a notable exception being the protocol with 8 different
values of Chi, using the PRIGo goniometer on the PX-III beamline at
the SLS, that has been "instrumental" in enabling large structures to
be experimentally phased by native SAD at 6keV).
It is great to see that there are many developments underway in
both hardware and software, leading gradually towards a reinstatement
of multi-orientation data collection as an off-the-shelf option for
those who are prepared to spend a bit more time to reliably get much
better data. The Proxima-1 beamline scientists at SOLEIL have always
been among the believers that the time would come when these efforts
would bear fruit, and what my group has been able to do in this area
owes a great deal to them.
With best wishes,
Gerard.
--
On Fri, Jul 14, 2017 at 01:18:35PM +0000, CHAVAS Leonard wrote:
> Reading back my email, when I mentioned 'just introduced', it is not giving
> justice to the reality and those who came up with the concept. I should have
> mentioned 'just reminded us', as the concept has been introduced quite a long
> time ago and few tens of communications. It is therefore a reminder that when
> coming to the will to collect good, clean and complete data, things aren't as
> simple as they would seem. Automation at our favourite beamlines do help by
> providing much more time thinking properly of the necessary strategies when
> coming to these difficult crystals so important to our hearts.
>
> Sorry again for the confusion. No hurt feelings I hope.
> Cheers, leo
>
> -
> Leonard Chavas
> -
> Synchrotron SOLEIL
> Proxima-I
> L'Orme des Merisiers
> Saint-Aubin - BP 48
> 91192 Gif-sur-Yvette Cedex
> France
> -
> Phone: +33 169 359 746
> Mobile: +33 644 321 614
> E-mail: leonard.cha...@synchrotron-soleil.fr
> -
>
> > On 14 Jul 2017, at 14:07, CHAVAS Leonard
> > <leonard.cha...@synchrotron-soleil.fr> wrote:
> >
> > Just to comment on what Graeme just introduced. We (and I know we are not
> > the first ones and not the only ones) are pushing our user community
> > towards this procedure as a standard: lowering the transmission (less
> > juicy, yet...) and getting few data with various chi. It does help greatly
> > in getting fully complete data, with no loss in resolution. Just fantastic!
> >
> > Cheers, leo
> >
> > -
> > Leonard Chavas
> > -
> > Synchrotron SOLEIL
> > Proxima-I
> > L'Orme des Merisiers
> > Saint-Aubin - BP 48
> > 91192 Gif-sur-Yvette Cedex
> > France
> > -
> > Phone: +33 169 359 746
> > Mobile: +33 644 321 614
> > E-mail: leonard.cha...@synchrotron-soleil.fr
> > -
> >
> >> On 14 Jul 2017, at 07:36, Graeme Winter <graeme.win...@diamond.ac.uk>
> >> wrote:
> >>
> >> Jacob
> >>
> >> If you have a complete 360 deg data set and your sample is still alive,
> >> and you have a multi-axis gonio, I would recommend rotating the crystal
> >> about the beam (ideally by ~ maximum scattering 2-theta angle) and
> >> collecting again. This would record your blind region as well as moving
> >> the reflections to different pixels, and (as a bonus) also will move
> >> reflections out from the tile join regions into somewhere they can be
> >> measured, which would not happen for small 2-theta shift.
> >>
> >> See http://scripts.iucr.org/cgi-bin/paper?BA0020 Figure 16 as excellent
> >> illustration of this.
> >>
> >> Biggest risk with this is getting *moving* shadows on the data on the
> >> second run, as an effective 45-50 degree chi shift (say) will usually be a
> >> pretty wide opening angle for a kappa gonio. XDS and DIALS both have
> >> mechanisms to deal with this, and automated processing packages are able
> >> to apply these given a reasonable understanding of the beamline.
> >>
> >> Also saves building 2-theta axes which can handle 92 kg ;o)
> >>
> >> Cheers Graeme
> >>
> >> On 13 Jul 2017, at 21:00, Keller, Jacob
> >> <kell...@janelia.hhmi.org<mailto:kell...@janelia.hhmi.org>> wrote:
> >>
> >> I thought there was a new paper from the Pilatus people saying fine
> >> slicing is worth it even beyond the original 1/2 mosaicity rule?
> >>
> >> I would think, actually, more gains would made by doing light exposures
> >> at, say, 1/3 mosaicity, collecting 360 deg, then shifting the detector in
> >> 2theta by a degree or two to shift uniformly the spots to new pixels,
> >> maybe accompanied by a kappa change. One would have to remember about the
> >> two-theta when processing, however!
> >>
> >> JPK
> >>
> >> -----Original Message-----
> >> From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Gerd
> >> Rosenbaum
> >> Sent: Thursday, July 13, 2017 3:40 PM
> >> To: CCP4BB@JISCMAIL.AC.UK<mailto:CCP4BB@JISCMAIL.AC.UK>
> >> Subject: Re: [ccp4bb] weird diffraction pattern
> >>
> >> Dear Gerard,
> >>
> >> my "sound like a sales person" was meant as poking a little fun - nothing
> >> serious, of course.
> >>
> >> I and our users like our not-so-new-anymore Pilatus3 6M. It's a great
> >> detector in many ways. But, there is a lot of hype that this detector
> >> solves all-problem, for instance fine slicing that is claimed to be only
> >> possible with a pixel array detector. People get carried away and use
> >> 0.01 degree slices even as the mosaicity of their sample is, say, 0.3
> >> degree. Slicing beyond 1/3 of the mosaicity will gain you very little -
> >> only more frames, more processing time.
> >>
> >> This discourse is already drifting away from the original topic of the
> >> thread so I will comment on the other arguments you made like resolution
> >> in a private e-mail.
> >>
> >> Best regards,
> >>
> >> Gerd
> >>
> >> On 13.07.2017 14:00, Gerard Bricogne wrote:
> >> Dear Gerd,
> >>
> >> I can assure you that I have no shares in Dectris nor any
> >> commecial connections with them. What I do have is a lot of still
> >> vivid memories of CCD images, with their wooly point-spread function
> >> that was affected by fine-grained spatial variability as well as by
> >> irredicible inaccuracies in the geometric corrections required to try
> >> and undo the distortions introduced by the fiber-optic taper. By
> >> comparison the pixel-array detectors have a very regular structure, so
> >> that slight deviations from exact registering of the modules can be
> >> calibrated with high accuracy, making it possible to get very small
> >> residuals between calculated and observed spot positions. That, I
> >> certainly never saw with CCD images.
> >>
> >> I do think that asking for the image width was a highly
> >> pertinent question in this case, that had not been asked. As a
> >> specialist you might know how to use a CCD to good effect in
> >> fine-slicing mode, but it is amazing how many people there are still
> >> out there who are told to use 0.5 or even 1.0 degree image widths.
> >>
> >> Compensating the poor PSF of a CCD by fine slicing in the
> >> angular dimension is a tall order. With a Pilatus at 350mm from the
> >> crystal, the angular separation between 174-micron pixels is 0.5
> >> milliradian.
> >> To achieve that separation in the angular (rotation) dimension, the
> >> equivalent image width would have to be 0.03 degree. For an EIGER the
> >> numbers become 75 microns, hence 0.21 milliradian i.e. 0.012 degree.
> >>
> >> Hence my advice, untainted by any commercial agenda :-) .
> >>
> >>
> >> With best wishes,
> >>
> >> Gerard.
> >>
> >> --
> >> On Thu, Jul 13, 2017 at 01:25:08PM -0500, Gerd Rosenbaum wrote:
> >> Dear Gerard,
> >>
> >> you sound like a sales person for Dectris. Fine slicing is perfectly
> >> fine with CCD detectors - it takes a bit longer because of the step
> >> scan instead of continuous scan. The read noise issue is often
> >> overstated compared to the sample induced scatter background. If for
> >> fine slicing at 0.05 degree or less the diffraction peaks go too
> >> close to the read noise make a longer exposure - signal goes up,
> >> ratio signal to sample-induced-BG less, as for any fine slicing, same read
> >> noise.
> >>
> >> It would be helpful to analyze the dense spot packing along layer
> >> lines if we knew the wavelength and the sample-to-detector distance
> >> (assuming this is a 300 mm detector) and the rotation width - as you
> >> pointed out. That would help to distinguish between multiple crystals
> >> (my guess) and lattice translocation disorder. Fine slicing is
> >> definitely needed to figure out what the diffraction pattern at 120
> >> degree could tell you in terms of strong anisotropy .
> >>
> >> Best regard.
> >>
> >> Gerd
> >>
> >> On 13.07.2017 08:20, Gerard Bricogne wrote:
> >> Dear Tang,
> >>
> >> I noticed that your diffraction images seem to have been
> >> recorded on a 3x3 CCD detector. With this type of detector, fine
> >> slicing is often discouraged (because of the readout noise), and yet
> >> with the two long cell axes you have, any form of thick (or only
> >> semi-fine) slicing would result in spot overlaps.
> >>
> >> What, then, was your image width? Would you have access to a
> >> beamline with a Pilatus detector so that you could collect
> >> fine-sliced data?
> >>
> >> I would tend to agree with Herman that your crystals might be
> >> cursed with lattice translocation disorder (LTD), but you might as
> >> well try and put every chance of surviving this on your side by
> >> making sure that you collect fine-sliced data. LTD plus thick
> >> slicing would give you random data along the streaky direction. Use
> >> an image width of at most 0.1 degree (0.05 would be better) on a
> >> Pilatus, and use XDS to process your images.
> >>
> >>
> >> Good luck!
> >> Gerard
> >>
> >> --
> >> On Thu, Jul 13, 2017 at 01:21:02PM +0100, Tang Chenjun wrote:
> >> Hi David,
> >> Thanks for your comments. Although the spots become streaky in certain
> >> directions, I have processed the data in HKL3000 and imosflm, which
> >> suggested the C2221 space group (66.59, 246.95 and 210.17). The
> >> Rmerge(0.14), completeness(94.8%), redundancy(4.6) are OK. When I tried to
> >> run Balbes with the solved native structure, the molecular replacement
> >> solution was poor. So I ran Balbes with the split domains of the native
> >> structure. Although the solutions were also poor, I found the MR score of
> >> one solution above 35. On the basis of this solution, I tried to run
> >> Buccaneer and the Rfree could be 0.46. Unfortunately, there are four
> >> molecules in the asymmetric unit and it is to hard for me to reduce the
> >> Rfree further.
> >>
> >> All best,
> >>
> >> Chenjun Tang
> >>
> >>
> >> --
> >> This e-mail and any attachments may contain confidential, copyright and or
> >> privileged material, and are for the use of the intended addressee only.
> >> If you are not the intended addressee or an authorised recipient of the
> >> addressee please notify us of receipt by returning the e-mail and do not
> >> use, copy, retain, distribute or disclose the information in or attached
> >> to the e-mail.
> >> Any opinions expressed within this e-mail are those of the individual and
> >> not necessarily of Diamond Light Source Ltd.
> >> Diamond Light Source Ltd. cannot guarantee that this e-mail or any
> >> attachments are free from viruses and we cannot accept liability for any
> >> damage which you may sustain as a result of software viruses which may be
> >> transmitted in or with the message.
> >> Diamond Light Source Limited (company no. 4375679). Registered in England
> >> and Wales with its registered office at Diamond House, Harwell Science and
> >> Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
