On 09/16/2015 06:26 PM, Logan Giles wrote:
I am running Demeter 0.9.22 and trying import recent SSRL Binary files. I have the SSRL plugins enabled as well. The problem is when I try to import binary files, the program crashes.
It seems that something might have changed recently in SSRL BL 7-3 files because I can import July 2013 files but not July 2015. I have attached a NaMoO4 sweep at the Mo K-edge from each run for your testing. Immediately after trying to import the binary July 2015 files, the program immediately crashes and exits. The July 2013 binary opens right up.
When I look at the dathena.log file for the "2015 crash", everything looks normal until the end:
"Demeter version 0.9.22
At line 316 of file iff_rddata.fFortran runtime error: End of record"
Also, when I try to import the ascii files of the July 2013 or July 2015 data, I get an error as well, but the same error. I can fix this by changing two of the blank rows, which are the column labels for the data, to "BLANK" or something. I have attached these unedited ascii files as well, but I am more concerned with my binary problem. The reason for this is that I was recently sent some other SSRL binary files without their corresponding ascii files that also crash.
Logan, The fundamental problem here is that the SSRL binary and ascii files are not well documented. And, they both suck really hard as file formats. When I made the SSRLA and SSRLB plugins, I was working from examples that people had provided to me. (It has been something like 22 years since I was last at SSRL for an experiment, so I have no direct experience with these files.) To interpret the wacky binary formats, I followed the example that Sam had programed into sixpack. The only sense in which the plugins ever worked was in the sense that "they worked on the examples in front of me". On the computer I am sitting at, I am able to read the 2015 binary file. The 2013 binary file fails. I am guessing that is because there are a lot of ^M characters in that file that are not in my example data or in the 2015 file. Both ascii files fail. Your explanation appears to be correct. The plugin expects all of the columns to be named. It expects that the list of column labels ends in a blank line, with the data to follow. Your files have blank lines in the middle of the column labels. That breaks the plugin. I am not clear that any of this is my problem. I don't actually know the specification for either format. Three of your four examples fail to meet my expectation based off of examples I was given some years back. I don't think I should be expected to meet an ill-defined and moving target. If you or someone else wants to update the SSRLA or SSRLB filetype plugins to work better with actual files from SSRL, I would be very happy to accept that contribution. But fixing them myself on the basis of this small sample set is very low on my to-do list. If you intend to use Athena, your best bet would be to write yourself a little conversion program that leaves the data in a state that Athena can interpret. Another option is to use sixpack. B -- Bruce Ravel ------------------------------------ bravel@bnl.gov National Institute of Standards and Technology Synchrotron Science Group at NSLS-II Building 535A Upton NY, 11973 Homepage: http://bruceravel.github.io/home/ Software: https://github.com/bruceravel Demeter: http://bruceravel.github.io/demeter/