A suggestion for Improving GSAS-II

[FortLiy]

While using GSAS-II, I encountered two issues that I believe may be potential areas for improvement, and I would greatly appreciate your advice.

First, when processing a single 2D diffraction image (e.g., TIFF or CBF) by integrating it over different azimuthal angles across 360° (for example, one pattern every 5°), I usually export the results using the stacked CSV file option. However, I noticed that the exported datasets are not strictly ordered by azimuthal angle. Instead of being sorted as 0°, 5°, 10°, …, 355°, the data appear in a mixed order (for example: 0°, 20°, 25°, 30°, …, 100°, 105°, …, then 5°, 10°, 15°, …, 355°). This makes subsequent plotting and further data processing quite inconvenient. I am not sure whether this behavior is intentional or a limitation of the current implementation.

Second, I would like to ask whether GSAS-II can support batch 2D integration in a way similar to FIT2D or pyFAI, i.e., performing azimuthal integration for multiple 2D images automatically and exporting the integrated results as 2D (or image-like) outputs, such as TIFF files. At present, although azimuthal integration can be performed, it does not seem possible to apply this procedure efficiently to a large number of images in batch mode. In addition, the azimuthal ordering issue mentioned above further complicates such workflows.

**Based on these two points, I was wondering whether future versions of GSAS-II might allow:

• Automatic sorting of azimuthal slices by angle when exporting stacked CSV files; and

• More flexible batch processing options for 2D azimuthal integration and export.**

Thank you very much for your time and for your continued efforts in developing and maintaining GSAS-II. I would be grateful for any guidance or comments you may have.

[briantoby]

There are really two separate issues here

1. How to deal with getting integrated diffraction patterns out in consecutive order; my guess is they are being sorted alphanumerically, which is definitely not what one would prefer.
2. How to "batch" integration: For that there are a few different approaches already available:

• "Integrate all" can be used to perform integration on a series of images that have been read into GSAS-II. One needs to set the integration parameters for each image.
• "Auto Integrate" will do the same as "Integrate All" but following the settings for one image, but it will continue to read in and integrate more images as they are found in a designated directory (usually during data collection).
• "Integrate/PDF app" launches a separate application that does about the same as "Auto Integrate" but it is a separate program and as such should not have some of the memory issues that "Auto Integrate" has after handling many thousands of images. This was developed a few years ago, and then was put to the side with minimal testing. It probably needs more debugging/improvements if anyone is interested in it.

There is also an extensive scripting interface associated with GSAS-II. There is a code example showing how to do integration in a way that reuses intermediate results to improve speed: https://gsas-ii-scripting.readthedocs.io/en/latest/GSASIIscriptable.html#optimized-image-integration and another somewhat more complex example that shows how to distribute the computation across multiple cores: https://gsas-ii-scripting.readthedocs.io/en/latest/GSASIIscriptable.html#multicore-image-integration. (It should also be possible to use a cluster with some package like DASK).

All of these should handle "caking" (azimuthal binning) and for that matter PDF computation.

[briantoby]

The sorting issue (number 1, above) was addressed in update ccf0912 (see #304). By default histograms will now be displayed in the order they appear in the data tree, which will normally be in a sensible order w/r to the azimuthal angle