- Ifeffit - millenia.cars.aps.anl.gov

wavelet transforms for EXAFS
by Matt Newville 14 Apr '14

14 Apr '14

Hi Folks, It's been on my To-Do list for many years, and was one of the arguments for needing to be able to handle multi-dimensional arrays for EXAFS analysis. So I'm happy to say that the Continuous Cauchy Wavelet transform of Munuz, Argoul, and Farges (from American Mineralogist 2003) is now (only ten years late) available in Larch. See http://xraypy.github.io/xraylarch/xafs/wavelets.html for an example. The code (see https://github.com/xraypy/xraylarch/blob/master/plugins/xafs/cauchy_wavelet… ) is adopted from the matlab code of M Munoz and F Farges, and that publication should be used as the citation for this routine. I know there are other implementations of wavelet transforms for EXAFS.... suggestions for changes or additions are welcome, as is additional code. The ability to actually fit data in wavelet space is not yet implemented. This was sort of planned for, and so shouldn't be too difficult to do. If anyone is interested in trying to fit EXAFS data in wavelet space, please let me know. I try to avoid too many announcements about why you should be using Larch instead of Ifeffit, but this is a clear case of something that was impossible in Ifeffit, but added as a single file of code (less than 150 lines, including code documentation) to Larch. --Matt

1 0

Demeter: Problem closing communication to gnuplot
by George Sterbinsky 13 Apr '14

13 Apr '14

Hello, I am trying to learn to use Demeter following The Demeter Programmer Guide. When I attempt to run the first example script in the importing data section I get the following error message: Graphics::GnuplotIF (object 1): problem closing communication to gnuplot I also see the plot window flash open and then closed on my screen. I am using perl 5.16.1 on mac OSX 10.8.5. If anyone can provide any suggestions as to how I might correct this please let me know. Thank you, George

3 4

Athena Ubuntu 12.04 LTS
by David Pickup 10 Apr '14

10 Apr '14

Hello, I'm running Athena (Demeter 0.9.20) with Ubuntu 12.04 LTS. Every time I go to the 'align data' window (with data open), Athena closes and the following message appears in the terminal: Usage: Wx::ComboBox::GetClientData(THIS, n) at /home/dave/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/Demeter/UI/Athena/Align.pm line 161, <F> line 1. Any suggestions on how to fix this problem. Thanks, Dave -- ----------------------------------------------------- Dr Dave Pickup School of Physical Sciences Ingram Building University of Kent Canterbury CT2 7NH Tel. 01227 823276 Fax. 01227 827558

2 2

Dafs - DIFFKK
by Alessandro Lisboa 09 Apr '14

09 Apr '14

Dear, My name is Alessandro Lisboa. I am a phd student of physics in Brazil - University of Brasilia. In the last February was held the first experiment DAFS in the Laboratório Nacional de Luz Síncrotron of Brazil. I performed this experiment and now I'm trying to analyze the data. I am having difficulty to establishing a procedure for analysis. I've read many things about. I tried to generate the diffkk.inp but I can not get result. I do not know what I'm doing wrong. I ask, please, help me with a procedure to analyze. For example, what is the sequence of files that need to create and run? I would be eternally grateful for your help. Regards, Alessandro Lisboa -- ----- *M.Sc. Alessandro F. Lisboa MoreiraPh.D. Student Complex Fluids GroupUniversidade de Brasília (UnB) - Instituto de FísicaBrasília/DF (Brazil)*

3 2

Larch: problems importing feff paths
by Johan Nilsson 09 Apr '14

09 Apr '14

Hello, I'm experimenting a bit with exafs fitting in Larch but I've come across a problem when I try to import my feff paths. Basically what happens is: $ larch Larch 0.9.22 (12-Dec-2013) M. Newville, T. Trainor using python 2.7.5, numpy 1.7.1, wx-enabled, wx version 2.8.12.1 larch> path = feffpath('feff0001.dat') file <stdin>, line 0 IndexError: list index out of range path = feffpath('feff0001.dat') ^^^ larch> I don't know if this is an issue with my input file to feff or if this is some sort of bug in Larch. I wrote the feff.inp from scratch using a template and the structure is supposed to be bulk PdO. I've attached my feff.inp and feff0001.dat if someone wants to try and reproduce the problem. I tried another set of paths that was calculated for FeO using an input file from webatoms and those appear to import without issues. I've attached those as well in a zip if someone wants to compare the two sets. I'm running Ubuntu 13.10 on my PC. Best regards, Johan

2 1

D-Atoms program, common positions and occupancies
by Moneeb Shatnawi 09 Apr '14

09 Apr '14

Dear Robert Gordon, Hello, Thank you so much for the reply. Yes, it turned out that I was using a relaxed model of CdSe where I should have changed the space group accordingly. When I replaced the input file with the correct one, everything went fine with no error messages, I appreciate your help, Moneeb

1 0

my backlog of Demeter chores
by Bruce Ravel 08 Apr '14

08 Apr '14

Hi everyone, For the last couple of weeks, I have been having trouble finding time to address the bugs that have been reported. Moneed Shatnawi, Alexander Britz, Matt Frith, Mengling Stuckman, Alison Tebo, and Thomas Huthwelker have all asked reasonable questions about actual issues with the software. I am writing today to assure them that they are on my mind, but there haven't been enough hours in the day or days in the week recently for me to address the problems. But I will! Soon, I hope. Cheers, B -- Bruce Ravel ------------------------------------ bravel(a)bnl.gov National Institute of Standards and Technology Synchrotron Science Group at NSLS --- Beamlines U7A, X24A, X23A2 Building 535A Upton NY, 11973 Homepage: http://xafs.org/BruceRavel Software: https://github.com/bruceravel

1 0

D-Atoms program, common positions and occupancies
by Moneeb Shatnawi 07 Apr '14

07 Apr '14

Dear Bruce Ravel, Hello, I am Moneeb Shatnawi from the University of Jordan. I have a question and I appreciate your help in advance. I have installed the Demeter program (version 0.9.18) and I tried to use your (D)Atoms program using the attached input files. When I try to run atoms, I get a warning message stating that two sites generate one or more common positions and their occupancies sum to more than 1. (attached also the warning message that I got). If I ignore this warning message and try to run FEFF, the program crashes. When I change the space group to P 1 (as indicated by the message) , the program runs well. My question is, could you please figure out the problem with these input files, so that I can run them with the correct space group? Thank you so much in advance, Moneeb

2 1

Re: [Ifeffit] Problem with importing projects from ATHENA into ARTEMIS
by Matt Newville 07 Apr '14

07 Apr '14

Hi Alexander, I think you may not alone in having this issue. You should be using normalized chi(k) in Artemis, but I don't think Artemis would be reading chi(k) from the project file incorrectly.... Perhaps there is something strange about how you're doing the normalization? Or perhaps it is just a question of what k-weighting is being used for the plot. Unfortunately, the PNGs I see have been cropped and don't show the labels of the axes. I'm sending this to the Ifeffit mailing list, where you'll probably get a more complete answer. On Mon, Apr 7, 2014 at 9:57 AM, Britz, Alexander <alexander.britz(a)xfel.eu> wrote: > Dear Mr. Newville, > > I came across a problem when I import an ATHENA project after normalization into ARTEMIS. Maybe you could tell me who to contact about this problem. Let me try to explain it in few words: > > I normalize my EXAFS data in ATHENA and safe it a s a .prj file. When I open the .prj file in ARTEMIS I noticed, that the amplitude of some oscillations have changed. When I save the chi(k) as .txt, this problem does not occur. When I open the chi(k) text file in ARTEMIS, the normalization and the amplitude of the oscillations are exactly the same as in ATHEN. > > I have attached a .png file for the EXAFS in k-space. It is the same .prj file, one time opened in ARTEMIS, one time in ATHENA. To be more specific, the amplitude of the oscillation at k=3 is -1.4 and -1.6, respectively. > > Thank you very much for your help in advance! > > Best regards from Hamburg, > Alexander > > ________________________________________ > Alexander Britz > European XFEL GmbH > alexander.britz(a)xfel.eu > Tel. +49 (0)40 8998-6986 > Fax +49 (0)40 8998-1905 > www.xfel.eu/de > > Postadresse: Notkestraße 85, 22607 Hamburg > Sitz: Albert-Einstein-Ring 19, 22761 Hamburg > > Geschäftsführer: Prof. Dr. Massimo Altarelli, Dr. Claudia Burger > Registriert als European X-Ray Free-Electron Laser Facility GmbH > beim Amtsgericht Hamburg, HRB 111165 > > > > -- --Matt Newville <newville at cars.uchicago.edu> 630-252-0431

2 1

Peaks in MCA spectra
by George Sterbinsky 02 Apr '14

02 Apr '14

Hello, I am writing with a general XAS question. It does not necessarily pertain to Ifeffit, however, I think the topic is something some, maybe most, list members will be knowledgeable about. So it seems like this list is a good place to post this question. On to the question. I have attached a plot of a MCA spectrum collected with a vortex silicon drift detector. The spectrum is actually the average of several spectra, all collected in the post edge region of the Co L-edge. The spectra were averaged to reduce noise. The three peaks result from fluorescence from carbon, oxygen, and cobalt. Low-energy shoulders on the Co and O peaks are also observed. These can be seen as the regions of the spectrum that are not well reproduced by the fit. The main reason I included the fit in the plot is to illustrate the presence of these shoulders, particularly in the oxygen florescence, where the additional intensity is not so obvious. I am writing to see if anyone has any suggestion as to what the origins of these peaks might be. They are not due to additional elements, as they appear at the same incident energies as the main florescence peaks, i.e. the Co shoulder appears at the same incident energies as the main Co peak, and the O shoulder appears at the same incident energies as the main O peak. It is possible that the peaks result form other transitions. Considering Co, the main peak is due to L3/L2-M4 transitions, and the shoulder is in a position that could be consistent with L3/L2-M1 transitions. However, by fitting the peaks with Gaussians, one finds an area for the shoulder that is about 25% of the area of the main peak. This is significantly larger than what one might expect from tabulated transition strengths like those given in Hephaestus. To summarize, does anyone know what these shoulders might result from if not lower energy transitions? If they are low energy transitions, why would the relative transition strengths differ from tabulated values? Thank you, George

3 9