Dear Ifeffit users, Sorry if it's an idiot question, but I'm in troubles when trying to work with my L3-Pb absorption data with Athena. I'm a beginner with the Ifeffit stuffs... Also, sorry if this report is not correctly posted, but I will try to give you the maximum information I can... Let's go. The data were taken at the Brazilian syncrotron laboratory, and the "important" data are in columns 3 (energy), 4 (Io) and 6 (It). The file is of the following form: "Data" "Hora" "Ponto X" "CION1(CURTA)" "CION3(Longa)" "CION2(Média)" "Det. D" "Translonga" "Transmédia" "Det. G" "Det. H" "Det. I" 04/02/04 12:32:51 12899.99 1671379 865008 1244452 0 0.658666 -0.363712 0 0 0 04/02/04 12:32:54 12901.16 1668799 863916 1242264 0 0.658384 -0.363215 0 0 0 04/02/04 12:32:57 12904.32 1661863 860550 1237862 0 0.658123 -0.363569 0 0 0 04/02/04 12:33:00 12905.99 1660709 860007 1237669 0 0.658059 -0.364045 0 0 0 04/02/04 12:33:03 12907.65 1656852 858657 1236381 0 0.657305 -0.364574 0 0 0 04/02/04 12:33:05 12909.82 1655818 858151 1236604 0 0.657270 -0.365344 0 0 0 04/02/04 12:33:08 12912.15 1655627 857952 1236890 0 0.657387 -0.365807 0 0 0 04/02/04 12:33:11 12913.82 1655763 858599 1238443 0 0.656715 -0.366308 0 0 0 When I try to open it, with the latest version (ifeffit-1.2.6) installed in a Windows XP computes, Athena says that the file has fewer than 10 data points. And the following message was trapped by Athena: Athena0.8.030warnC:\Arquivos de programas\Ifeffit\horae\stash\ATHENA.TRAPCODE(0x 3be700c) at athena line 1349 main::__ANON__('Use of uninitialized value in concatenation (.) or string at ath...') called at athena line 3658 main::read_raw('D:/meus documentos/LNLS/D04B-XAS 1832-03/data/B040006.DAT', '', undef, 'SCALAR(0x3a80b78)') called at athena line 3516 main::read_file(0) called at /PerlApp/Tk.pm line 340 eval {...} called at /PerlApp/Tk.pm line 340 Tk::MainLoop() called at athena line 1411 The files in the /examples/Athena folder open correctly. Do I need to "clean" the data, leaving only the desired columns, E, Io and It? Again, sorry if it's a dumb question and if the report is incomplete... Thank you in advance Mauricio ************************************** Maurício Antonio Pereira da Silva Departamento de Física Grupo de Dinâmica Molecular Universidade Federal de São Carlos - UFSCar Via Washington Luiz, km 235 Vila Monjolinho 13565-905 São Carlos - SP Brasil Tel: +55 (16) 33 51 82 22, ramal 262 Fax: +55 (16) 33 61 48 35 *************************************** --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.742 / Virus Database: 495 - Release Date: 19/8/2004
On Friday 27 August 2004 09:04 am, Mauricio wrote:
I'm in troubles when trying to work with my L3-Pb absorption data with Athena. I'm a beginner with the Ifeffit stuffs... Also, sorry if this report is not correctly posted, but I will try to give you the maximum information I can...
Let's go. The data were taken at the Brazilian syncrotron laboratory, and the "important" data are in columns 3 (energy), 4 (Io) and 6 (It). The file is of the following form:
Hi Mauricio, It seems that the problem is with the first two columns, which contain date and time information. Athena relies upon Ifeffit's notion of what is and is not a line of data in a file. For Ifeffit, a line of data is a line which contains only strings which are recognizable as floating point numbers. Strings such as "04/02/04" and "12:32:51", though obvious to the human reader, are not interpretable as numbers by Ifeffit. So Ifeffit reports that it could not find *any* lines containing data in your file. Athena should have complained about that without issuing an error message, but apparently there remains a problem. The immediate solution is to edit the data file and remove the first two columns of data. I suspect that Ifeffit and Athena will then be happy with your data files. There are two more permanent solutions. 1. Convince the person who maintains the data acquisition software at your beamline to use a file format that Ifeffit can read. Alternately, disable the recording of date and time with every data point. Frankly, it seems silly to record the date at every point. EXAFS scans are typically on the order of minutes. It should be sufficient to record the data once at the top of the file. The same is probably true of the time, although I can imagine situations where the time is useful information. In that case, recording the start time at the top of the file and recording a column of elapsed seconds serves the same purpose and would not confuse a program expecting floating point numbers in the data columns. 2. It may be impossible for some reason to have the data file format changed, but there are people doing exafs and wanting to use Athena. That was the case with beamline X10C at NSLS. There is special code in Athena to recognize a data file from X10C and rewrite it in a way that Ifeffit will handle. I am willing to do the same for other beamlines, but I would need several examples of data to work with. B P.S. That was a dandy problem report. You gave me sufficient information to understand the problem, which is all I ever ask for. Thanks! -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 405 Naval Research Laboratory phone: (1) 202 767 2268 Washington DC 20375, USA fax: (1) 202 767 4642 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
Dear Feffusers, Thank you all for your attention. The problem was in fact in the first two columns containing non-numerical characters; Athena now reads my data correctly. Thanks Bruce, Norbert and Matt for the valuable tips and suggestions... Mauricio ************************************** Maurício Antonio Pereira da Silva Departamento de Física Grupo de Dinâmica Molecular Universidade Federal de São Carlos - UFSCar Via Washington Luiz, km 235 Vila Monjolinho 13565-905 São Carlos - SP Brasil Tel: +55 (16) 33 51 82 22, ramal 262 Fax: +55 (16) 33 61 48 35 *************************************** --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.745 / Virus Database: 497 - Release Date: 27/8/2004
Dear Mauricio, following up to Bruce's reply, I suggest using a small script (PERL, awk, whatever you prefer) to extract just the information needed by ATHENA/ARTEMIS. This is what I usually do with my raw data. In your case, e.g. a gawk '{print $3,$4,$5,$6}' infile > outfile (or whatever columns you need) would do a great job. In case you have bash available, you can even make a fancy loop: for i in `ls *.dat`;do gawk '{print $1,...}' $i > $i.ext ; done which makes you a ".dat.ext" out of every ".dat" file. Feel free to ask me in case you want to know a bit more on linux-scripting - it's anyway a good tool for spectroscopy :) Cheers, Norbert -- Dr. rer. nat. Norbert Weiher (weiher@chem.ethz.ch) Institute for Chemical and Bioengineering - ETH Hönggerberg HCI E 117 - 8093 Zürich - Phone: +41 1 63 3 48 32
Mauricio, Bruce and Norbert gave good answers about why Ifeffit chokes on this data, and what might be done about it. One question for you is: how are these data files normally read? Does the beamline provide some utilities for dealing with these? Ifeffit's read_data() was meant to read ASCII columns of floating point numbers only. That's certainly limited. It might be remarkable that it's been good enough so far, or it might be that enough beamline data is close enough to this format already. I originally expected that either beamline-specific read_XXX() commands would have to be added or that the front ends would have to translate the data and not use read_data(). It's probably a lot easier to do the translation in perl, awk, or any editor with search-and-replace (you could just replace ':' and '/' with '0' and read_data() would work) than write a specific routine in Fortran to read this data. I'd be willing to add other read_XXX() commands, but have not seen the need yet. It's also possible to modify read_data() to ignore non-numerical columns. Do others have beamline data file formats that Ifeffit/Athena has problems with that should be handled? --Matt
I often make use of Artemis' option of plotting the sum of paths (with current parameters) to double check the starting values for a full fit. Under the sum of paths (no fit) option, there are two sub-options, one "use all paths" and "use only selected paths". I believe that regardless of which option is chosen only selected paths are summed. I noticed this as I had a very unique path that really stuck out and using the sum all paths option I could turn on and off its appearance by selecting or de-selecting this path. This was regardless of the fact that I had selected the "use all paths" sub-option. As the behavior one usually wants is to sum only selected paths, this is not a very serious problem, however, it is potentially misleading and ?probably easy to fix. This is with the latest version of artemis rc2. Paul
A trivial question perhaps... I understand that the Artemis source is being split into a development version and a stable version. For those (like me) who like to live on the bleeding edge, where will the various sources reside? In particular, will the update_horae script upgrade to the latest development version (or perhaps there should be a switch for using the development version so it can't be executed by accident)?
Paul, I'll look into the thing with the sum of paths. Thanks for the report.
A trivial question perhaps... I understand that the Artemis source is being split into a development version and a stable version. For those (like me) who like to live on the bleeding edge, where will the various sources reside? In particular, will the update_horae script upgrade to the latest development version (or perhaps there should be a switch for using the development version so it can't be executed by accident)?
Funny you should ask today because I was planning to answer your question by example later today! It is true that I am now maintaining two branches of Artemis. The stable branch is only getting bug fixes. The development branch, as you will soon see, aready as several significant new features as well as a facelift for its appearence. You bleeding edge sorts will soon have a lot to play with -- by which I mean, of course, a lot of new bugs to report ;-) The development version gets built and installed at the same time as the stable version when you build from source. That means that the horae_update script will automatically install both branches. The main program of the development version is called "diana" -- perhaps a little cutesy, but consistent with my naming theme. Additionally, there are a handful of files that get installed that are used only by the development version. It will, therefore, be very easy to switch back and forth between the to branches. For those who do not use the source tarballs (mostly Windows users) I won't be building executables of the development version until it has been tested for a while. I would like to avoid the confusion and difficulties from this spring and summer following the addition of atoms, feff, and the new project format. My hope is that the development process will weed out those bugs before the new code goes into wide use. My hope is to transition the development features into the stable branch in November or December. B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 405 Naval Research Laboratory phone: (1) 202 767 2268 Washington DC 20375, USA fax: (1) 202 767 4642 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
participants (5)
-
Bruce Ravel -
Matt Newville -
Mauricio -
Norbert Weiher -
Paul Fons