[Ifeffit] Binary SSRL Files crash upon import.

Bruce Ravel bravel at bnl.gov
Thu Sep 17 11:54:00 CDT 2015


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 at 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/



More information about the Ifeffit mailing list