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/

_______________________________________________
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit