| Attachments | |
|---|---|
| mrfmsk_darwin.tar.gz | 571K |
| mrfmsk_linux64.zip | 584K |
| mrfmsk_linux64.tar.gz | 584K |
| mrfmsk_darwin.zip | 571K |
Please also check the autoPROC home page and the news page for updates and snapshot releases.
The same issue as in previous versions 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.
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).
The scaling module aP_scale might behave unexpectedly if running with the (non-default) RunTruncate=no setting. In that case one would also need to set autoPROC_Scale_CreatePdf=no, i.e.
process ... RunTruncate=no autoPROC_Scale_CreatePdf=no ... aP_scale ... RunTruncate=no autoPROC_Scale_CreatePdf=no ...
Furthermore, some bogus error messages a la
/software/GPhL/20210224/autoPROC/bin/linux64/aP_scale_helper1: line 539: find_xml_link: command not found /software/GPhL/20210224/autoPROC/bin/linux64/aP_scale_helper1: line 540: find_cif_link: command not found
will be emitted by the program. These can be avoided via the environment variable LIBAPSCALE_SH, i.e.
export LIBAPSCALE_SH=$autoPROC_home/autoPROC/bin/linux64/libaPscale.sh # sh/bash - or - setenv LIBAPSCALE_SH $autoPROC_home/autoPROC/bin/linux64/libaPscale.sh # csh/tcsh
(and similar for MacOS, replacing "linux64" by "darwin" above). Those lines could be added to the $autoPROC_home/setup_local.sh and $autoPROC_home/setup_local.csh files, respectively:
echo "export LIBAPSCALE_SH=\$autoPROC_home/autoPROC/bin/linux64/libaPscale.sh" >> $autoPROC_home/setup_local.sh echo "setenv LIBAPSCALE_SH \$autoPROC_home/autoPROC/bin/linux64/libaPscale.sh" >> $autoPROC_home/setup_local.csh
Note: $autoPROC_home refers to the installation directory for autoPROC.
We've seen some long execution times for autoPROC on CentOS8 due to our distributed Gnuplot binary taking a very long time. 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!
The PDBx/mmCIF files written by autoPROC (typically called Data_1_autoPROC_STARANISO_all.cif and Data_2_autoPROC_TRUNCATE_all.cif) contain two items with the "gphl_" prefix - instead of the "pdbx_" prefix:
Because appropriate aliases exist, this should have no impact on the deposition process.
There is a problem in handling C2 spacegroups during the anisotropic (STARANISO) analysis: when the alternative I2 settings would provide a less oblique unit cell (i.e. beta angle closer to 90 degrees), the application of the cut-off surface (mask) to the full (scaled, but unmerged) data is not done correctly. This leads to incorrect data quality metrics (green "Table 1" in summary.html) for the anisotropic (STARANISO) analysis of those datasets.
An updated MRFMSK binary (allowing for internal C2/I2 re-indexing on-the-fly) will be included in the next release. You can already update your installation by downloading the relevant file
and replacing the binary in
$autoPROC_home/autoPROC/bin/linux64/mrfmsk
and/or
$autoPROC_home/autoPROC/bin/darwin/mrfmsk
with the binary provided in those tar/zip files.
Plese note that this has only an effect on the statistics reported in that "Table 1" and not for the actual data within e.g. staraniso_alldata-unique.mtz!.
If you see messages to that effect in your autoPROC standard output, the "binutils" package is probably not installed on your Linux system. Please install this e.g. via
sudo apt-get install binutils(for Debian-based Linux distributions like Ubuntu) or any other installation method provided by your particular Linux distribution. You can then check this via
which stringsto ensure it is available as expected.
Setting the parameter
autoPROC_AnalyseForPoorImageRanges="no"
as suggested in the release notes will not have the desired effect due to a logic flaw. To switch off the new automatic image-pruning capability, a user will have to set
process do_select1=0 do_select2=0 do_select3=0 ...instead. This will be fixed in the next release (thanks to E. terHaar for reporting).
The detector currently used on ESRF/MASSIF-1 seems to report the same serial number as the one on ID23-2 (which uses a very different goniostat setup, nammely a vertical instead of horizontal rotation axis). Therefore the new automatic system for specification of instrument parameters will pick incorrect values. This will hopefully be fixed in the next release if there is a way of distinguishing datasets from those two beamlines. We are working together with our colleagues at ESRF/MASSIF-1 on this.
The solution for the moment is to run with the do_setup=0 command-line argument (to completely disable that automatic instrument setup based on dataset meta-data information).