[Ifeffit] Pain of SSRL file formats

Webb, Samuel M. samwebb at slac.stanford.edu
Thu Sep 17 13:57:05 CDT 2015

I do agree with many of the previous comments on the state of SSRL binary XAS formats and I certainly won't defend them -- they are horrid and it took me quite a long time to figure out the format so that SIXPACK and others could read them.  Tragically, the format goes way back to the VMS days and is essentially in my view under to unsupported.  From my past experience, most of the problems I have had with the binary files is transferring them across FTP sites, where a bad choice of data transfer formats (non-explicit binary transfer) has been chosen. That tends to forever corrupt the file and it needs to be reFTP'd to be at all useable. This in itself is the main reason why I never use the binary data format.  The only real program that appears actually want to deal with SSRL binaries is EXAFSPAK.

Many people who like the VMS data collector still use the old data collection system, and that's a fine user preference.  In those instances,  those users will need to deal with their data in that preferred format, and if they chose to use that old collector, then I would normally presume that they know how to deal with that data.  However, there is no need for any user from SSRL to need to use the antiquated binary data formats. All the beam lines that have that somewhat ancient data collector all have an ASCII transfer utility and users (should) be told about that utility when they arrive.  Thus, there is no excuse for someone to have to deal with data in a binary format if they don't want to.

As for other beam lines (as well as XAS beam lines that are not on VMS anymore), there are newer XAS data collectors that collect data only in ASCII formats.  Granted, it is the slightly screwy SSRL ASCII still, in some effort to be backward compatible, but it is at least readable and manageable.  On a separate note,  I find that many users (and sometimes support personnel) will edit the standard beam line detector definitions to a point where many data analysis programs that I use (read SIXPACK) cannot read the data either.  That said, the newer data collectors at the beam line should (and do) produce readable data that should (and is) easily managed by both Athena as well as many other programs (at least SIXPACK).  

I haven't always followed the current trend in data file formats for XAS - has anyone ever decided on a common data format, or at least an interchange format?  


More information about the Ifeffit mailing list