Known Issues in 20210420 autoPROC release:


Introduction

Please also check the autoPROC home page and the news page for updates and snapshot releases.


Bruker Photon-II data in imgCIF/CBF format

The same issue as in previous versions (going back to 2017) still seems to exist. At least we haven't had any feedback to the contrary.

Please note that native SFRM formatted datasets should be fully supported in autoPROC.


Odd GPX2 behaviour on MacOS 10.15

We've had reports from users about some unexpected GPX2 pop-up windows appearing on MacOS 10.15 (this apparently didn't happen on previous 10.X versions). We are trying to recreate and analyse this, but in the meantime you can set the parameter autoPROC_CreateGpxPictures to "no" which will switch the generation of diffraction image pictures completely off. This can be done via an environment variable


  setenv autoPROC_CreateGpxPictures "no"            # csh/tcsh
    - or -
  export autoPROC_CreateGpxPictures="no"            # bash/sh

or on the autoPROC command-line


  process autoPROC_CreateGpxPictures="no" ...

You can still check processing and predictions using GPX2 via the created gpx.sh scripts (see standard output).


Potentially slow Gnuplot on CentOS8

With previous releases, we've seen some long execution times for autoPROC on CentOS8 due to the distributed Gnuplot binary taking a surprisingly long time. This should be fixed with this release, but if you still experience slowdowns, we would recommend the installation of an OS-specific version of Gnuplot on those systems.

As root, run

    yum install gnuplot

and as software installer run

    echo "setenv BDG_TOOL_GNUPLOT \"/usr/bin/gnuplot\"" >> $autoPROC_home/setup_local.csh
    echo "export BDG_TOOL_GNUPLOT=\"/usr/bin/gnuplot\"" >> $autoPROC_home/setup_local.sh

The setting of the environment variable BDG_TOOL_GNUPLOT will ensure the use of the newly installed OS-version of "gnuplot".

Remember that CentOS8 will reach end-of-life on December 31, 2021, while CentOS7 is still supported til June 30th, 2024!


Eiger2 CdTe detector at P14 (Petra-III) (fixed in 20210716 release)

Images written at P14@Petra-III with the new Eiger2 CdTe detector are not recognized by the currently distributed imginfo binary (the description in the mini-cbf files changed from "Eiger" to "EIGER"). Please replace your existing binary at

$autoPROC_home/autoPROC/bin/linux64/imginfo

with imginfo_linux64:

  mv $autoPROC_home/autoPROC/bin/linux64/imginfo $autoPROC_home/autoPROC/bin/linux64/imginfo.orig

  cp -p imginfo_linux64 $autoPROC_home/autoPROC/bin/linux64/imginfo

  chmod 0755 $autoPROC_home/autoPROC/bin/linux64/imginfo

If you have no write privileges for this: download imginfo_linux64 followed by

  chmod +x ~/Downloads/imginfo_linux64

and then run autoPROC using

  process imginfo=~/Downloads/imginfo_linux64 ...

You should also do the same operation for the gpx2 binary (downloading gpx2_linux64 and/or gpx2_darwin) or add the setting

  process ... autoPROC_CreateGpxPictures=no ...

to your command line (switching off generation of prediction pictures, which will fail for the same reason as above).

Note: this will be fixed in the next release.


64-bit pixel masks in HDF5 datasets (fixed in 20210716 release)

We are aware of some recent HDF5 (Eiger) datasets where you might encounter an early error (Segmentation fault, followed by error code "x_index-0020"). This can happen when the pixel mask in the master.h5 file is stored as an array of 64-bit data (and not as 32- or 16-bit data). It is not yet clear why such a change was introduced: the pixel masks typically holds way below the more often used 32 bits anyway. We are in contact with beamline/synchrotron staff to find out the underlying reason for this change.

An updated hdf2mini-cbf binary will be included in the next release. In the meantime you can download the hdf2mini-cbf_linux64.zip or hdf2mini-cbf_darwin.zip file and replace the binary in your installation via e.g.

  mv -vi $autoPROC_home/autoPROC/bin/linux64/hdf2mini-cbf $autoPROC_home/autoPROC/bin/linux64/hdf2mini-cbf.orig

  mv -vi /where/ever/unzipped/hdf2mini-cbf $autoPROC_home/autoPROC/bin/linux64/hdf2mini-cbf

  chmod 0755 $autoPROC_home/autoPROC/bin/linux64/hdf2mini-cbf

Alternatively (and if you don't have permission to write in that directory) you could run with

  process hdf2minicbf=/where/ever/unzipped/hdf2mini-cbf ...

As a fall-back option you could also add

DistributeBackgroundImagesForHdf5=no

to your command-line. But be aware that the distribution of images over a wider angular range for the initial background determination is done (by default) for a good reason: it provides for a smoother background table that could have knock-on effects in spot search and integration. The above temporary fix is therefore not intended as a general setting.

Update: as of 25th June 2021 (thanks Graeme Winter) this change has been reverted on beamline I03 (DLS).


Problems processing I04-1 (DLS) datasets from new Eiger 2XE 9M (E-18-0123) (fixed in 20210716 release)

The newly installed Eiger 2XE 9M detector on beamline I04-1 at Diamond Light Source creates HDF5 datasets that

  • provide identical files both as *_master.h5 and *.nxs (you can check this by running e.g. md5sum on those files)
  • have renamed the goniometer omega value from "omega" to "gonomega" (as of 21st June 2021)

The latter causes autoPROC to fail since no angular image width can be extracted (via imginfo).

Our colleagues at DLS have looked into this and reverted back to calling this "omega" (as of 25th June 2021 - thanks to Graeme Winter). The next release of autoPROC will contain support for those (intermediately created) files as well.