Pilatus at Proxima1


Status 20111014

Images from the Pilatus detector at Proxima1/Soleil will currently not work correctly due to

  • distance stored in mm (without a unit declaration) instead of default m
    • you could override this by using eg dist=100 on the process command-line
  • Omega angle stored in Chi parameter (important for multi-axis Phi scans)
    • for single scan datasets or pure Omega-scan multi-axis datasets this should have no effect
    • for other datasets it might be necessary to set EnsureConsistentIndexing=no on the process command-line

There are some other, non-critical issues with the current (20111014) header format that we're working on together with the Proxima1 beamline staff.

Status 20111030

Some changes have occured at the beamline to correct several header issues. Due to certain limitations in the gerneal header format (and the specific capabilities of the Proxima1 beamline), there are still a few issues that need to be worked around. Our current recommendation is

  • save the file SoleilProxima1.macro as $autoPROC_home/autoPROC/macros/SoleilProxima1.macro and make it readable:
      % chmod 0644 $autoPROC_home/autoPROC/macros/SoleilProxima1.macro
      % chmod 0755 $autoPROC_home/autoPROC/jiffies/imginfo_soleil_pilatus_201109.sh
  • create a symbolic link with:
      % cd $autoPROC_home/autoPROC/bin/linux   && ln -sv ../../jiffies/imginfo_soleil_pilatus_201109.sh .
      % cd $autoPROC_home/autoPROC/bin/linux64 && ln -sv ../../jiffies/imginfo_soleil_pilatus_201109.sh .
      % cd $autoPROC_home/autoPROC/bin/darwin  && ln -sv ../../jiffies/imginfo_soleil_pilatus_201109.sh .
  • use the new macro (on top of all other arguments) for processing Pilatus 6M images from the Proxima1/Soleil dbeamline:
      % process -M SoleilProxima1 ...

This should process your Proxima1/Pilatus images (before and after the latest changes) correctly. If there are any problems or unexpected results - please let us know asap!

Pilatus 2M at SLS PXIII (20111212)

Two issues need to be manually corrected when processing images from the new Pilatus 2M detector installed on the SLS PXIII beamline:

  • the sensor thickness recorded in the image header is wrong: should be 0.000450 instead of 0.000320.
    • this means adding the keyword autoPROC_XdsKeyword_SENSOR_THICKNESS
  • pixels directly next to the gaps have the wrong intensity (by a factor of 1.4)
    • so manual masking of the gaps including the lines at either side is required (with the keyword autoPROC_XdsKeyword_UNTRUSTED_RECTANGLE)

The easiest is to place the file SLS-PXIII-Pilatus2M.macro into your $autoPROC_home/autoPROC/macros directory and run autoPROC with the command:

% process -M SLS-PXIII-Pilatus2M ...

or using the relevant keywords by hand:

autoPROC_XdsKeyword_UNTRUSTED_RECTANGLE=" 486 496 0 1680| 980 990 0 1680| 0 1476 194 214| 0 1476 406 426| 0 1476 618 638| 0 1476 830 850| 0 1476 1042 1062| 0 1476 1254 1274| 0 1476 1466 1486"

Thanks to Dirk Reinert, Herman Schreuder and Joachim Diez.

Update 20120224

Since 25th January 2012, the image header was corrected to now have

# Silicon sensor, thickness 0.000450 m

So explicit setting of this parameter (see above) is no longer be required.

Furthermore, the use of a flat-field correction means that masking the pixels of the gap (and one line surrounding it) is no longer necessary. This should be visible in the image header through a line like

# Flat_field: FF_p2m0109_E12398_T6199_vrf_m0p20.tif

Thanks to Vincent Olieric.

Non-aligned beamstop holder

If the beamstop holder is not aligned with the rotation axis (or vice-versa), the area behind that shadow is not automatically discarded due to high Lorentz-Polarization. This means that one completely relies on the automatic beamstop masking and/or outlier rejection done by the integration and scaling program. Since any problem with masking this region will result in a large number of reflections with wrong intensities, the normal outlier handling might break down.

There are two solutions:

  • align the beamstop holder with the rotation axis (if this is possible given the spatial restrictions)
  • manually mask the affected region (using the various geometric primitives available)

To help with the second approach, you could use the script line2rect.sh to define a series of squares along a given line. The idea is to make the generation of an adequate autoPROC command-line argument easier. For that you want to

  • copy the line2rect.sh file into $autoPROC_home/autoPROC/jiffies
  • make the script executable with chmod 0755
  • create a symbolic link with:
      % cd $autoPROC_home/autoPROC/bin/linux   && ln -sv ../../jiffies/line2rect.sh .
      % cd $autoPROC_home/autoPROC/bin/linux64 && ln -sv ../../jiffies/line2rect.sh .
      % cd $autoPROC_home/autoPROC/bin/darwin  && ln -sv ../../jiffies/line2rect.sh .
  • use a display program like adxv to define two points at the beginning and end of the beamstop holder (on point will be at the edge of the detector, the other near the beam centre)
  • run the tool line2rect.sh giving the x and y coords (in pixels) from both points, and a 5th parameter to define the width of the box that will be drawn (determine this from measuring the width of the beamstop holder shadow at its widest point). E.g:
      % line2rect.sh 410 0 517 514 24
  • take the resulting (very long!) autoPROC_XdsKeyword_UNTRUSTED_RECTANGLE line as-is as an argument to autoPROC, eg
      % process ... autoPROC_XdsKeyword_UNTRUSTED_RECTANGLE="396 424 -14 14|401 429 10 38|406 434 34 62|411 439 59 87|416 444 83 111|421 449 108 136|426 454 132 160|431 459 157 185|436 464 181 209|441 469 206 234|446 474 230 258|452 480 255 283|457 485 279 307|462 490 304 332|467 495 328 356|472 500 353 381|477 505 377 405|482 510 402 430|487 515 426 454|492 520 451 479|497 525 475 503"

One could use the same masking parameters for a large number of datasets - as long as the shadow doesn't change (probably distance-dependent in most cases).

Update: newer versions of XDS have the UNTRUSTED_QUADRILATERAL keyword that can be used now.

Pilatus 6M at ESRF/ID29 (20121102)

The mini-CBF header written on that beamline specifies

# Oscillation_axis omega

without also specifying an Omega item. The controller software from Dectris will be updated very soon, to allow specification of the Omega angle (even more important for Phi-scans on multi-axis goniostats).

In the meantime, the override-mechanism can be used:

  • save the file imginfo_ESRF_ID29.sh as $autoPROC_home/autoPROC/jiffies/imginfo_ESRF_ID29.sh and make it executable ('chmod 0755 ...')
  • run autoPROC with
      % process imginfo=$autoPROC_home/autoPROC/jiffies/imginfo_ESRF_ID29.sh ...

XDS Version: March 30, 2013

There have been a lot of format changes in several files created by the latest XDS Version: March 30, 2013. This makes it incompatible for use with the current version of autoPROC. We are working on providing this compatibility as soon as possible. In the meantime, please keep using the previous version of XDS (September 26, 2012) with autoPROC, eg. with

% process xds=/where/ever/20120926/xds_par ... -d 01 | tee 01.lis