Known Issues in 20230726 autoPROC release:


Introduction

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


ID23-1 (ESRF) writing incorrect meta-data into HDF5 master.h5 files (20230926-20231108)

To help users of the ESRF ID23-1 beamline (from 26th Sep to 8th Nov 2023) overcome processing problems due to incorrect image-width values in the metadata, we are providing a so-called imginfo-wrapper to compute a corrected oscillation angle directly from the metadata: imginfo_ESRF_ID23-1.sh that you should be able to use via

    process ... imginfo=/where/ever/imginfo_ESRF_ID23-1.sh ...

(special thanks to Olof Svensson, Max Nanao and the ESRF team for in-depth analysis of the underlying problem). See also the ID23-1 Troubleshooting page for further details.


ID23-2@ESRF writing incorrect meta-data into HDF5 master.h5 files

As of 3rd May 2023 (and most likely before and after that date), *_master.h5 files created at beamline ID23-2 of ESRF contain incorrect meta-data: the omega axis is described as (-1,0,0) when it should be (0,1,0).

Beamline staff is aware of that but are currently unable to correct this (it is due to an inability of the detector firmware to allow modification of the instrument description - being stuck with a horizontal rotation axis of a fixed sense of rotation).

A user has therefore two options:

  • Run autoPROC with temporary overrides a la
    process XdsFormatSpecificJiffyOverwrite=no autoPROC_XdsKeyword_ROTATION_AXIS="0 1 0" ...
  • Correct the *_master.h5 file directly and only once with a short h5py script (see FaqCorrectHdf5):
    fix_omega.py some_master.h5

Both solutions should provide you with correct autoPROC processing - even if we slightly prefer the second solution (since archiving the dataset and revisiting it in a few years time becomes easier). Of course, the best/proper solution is a fix directly at the beamline (using a fixed version of the detector firmware) so that correct meta-data is available within those HDF5 files.


imginfo warnings for Eiger/HDF5 data

We've had reports about warning messages of the form

img2xds >>>
img2xds >>>   >>> imginfo >>> Extracted from file ./HDF5_1/imginfo.log :
img2xds >>>   >>> imginfo >>>
img2xds >>>   >>> imginfo >>> WARNING: expected unit "degree" for item "/entry/sample/goniometer/omega_range_total" - but found unit "A<88>^B" (length=6)!!
img2xds >>>   >>> imginfo >>>
img2xds >>>

that we are currently investigating. The underlying cause is a change in string encoding of the "units" attribute for specific items (like "degree" etc). We are not 100% sure yet if that is due to some local configuration or a change in the SIMPLON software.


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

With previous releases, we've seen some long execution times for autoPROC due to our distributed Gnuplot binary taking a surprisingly long time. We would recommend the installation of an OS-specific version of Gnuplot on your systems, e.g. on CentOS/RHEL/Fedora systems:

As root, run

    yum install gnuplot

or (if you don't need a GUI for Gnuplot)

    yum install gnuplot-nox