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

Re: [Ifeffit] Is good EXAFS data possible with 0.01 transmission coefficient
by Damon Turney 26 Jul '13

26 Jul '13

Thank you Matthew Marcus. To answer your questions: Most of the transmission loss is due to the Mn particulates. The 0.01 transmission coefficient (a.k.a. ~4 absorption lengths) is in regards to xray energies above the absorption edge. Below the absorption edge the transmission coefficient should be 0.1 to 0.4. I don't understand the definition of "edge jump" or how to calculate it (but trust me I will be reading up on all of this ASAP). Anyway, the transmission coefficient contains all the required information. I doubt that I have "pinhole effect" because the MnO2 is small particulates (10 micron diameter) evenly dispersed throughout the 300 micron thick sample, so I doubt there are any pinholes. Matthew are these "distortions" that you speak of the same thing as "harmonics" that I've read about in "XAFS for Everyone" that can complicate XAFS analysis? Thanks, Damon On Thu, Jul 25, 2013 at 5:09 PM, <ifeffit-request(a)millenia.cars.aps.anl.gov> wrote: > Send Ifeffit mailing list submissions to > ifeffit(a)millenia.cars.aps.anl.gov > > To subscribe or unsubscribe via the World Wide Web, visit > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > or, via email, send a message with subject or body 'help' to > ifeffit-request(a)millenia.cars.aps.anl.gov > > You can reach the person managing the list at > ifeffit-owner(a)millenia.cars.aps.anl.gov > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ifeffit digest..." > > > Today's Topics: > > 1. Is good EXAFS data possible with 0.01 transmission > coefficient (Damon Turney) > 2. Re: Is good EXAFS data possible with 0.01 transmission > coefficient (Matthew Marcus) > 3. Re: Is good EXAFS data possible with 0.01 transmission > coefficient (Scott Calvin) > 4. Re: Is good EXAFS data possible with 0.01 transmission > coefficient (Scott Calvin) > 5. Re: Is good EXAFS data possible with 0.01 transmission > coefficient (Matthew Marcus) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 25 Jul 2013 16:07:57 -0400 > From: Damon Turney <dturney(a)ccny.cuny.edu> > To: ifeffit(a)millenia.cars.aps.anl.gov > Subject: [Ifeffit] Is good EXAFS data possible with 0.01 transmission > coefficient > Message-ID: > <CAOHT-BNp4s8fjUdQnwfgkxaFAzDrKrDtyX1BMenM_HWByeyiQw(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi IFEFFIT community, > > I will make measurements soon at Brookhaven's NSLS to do EXAFS, and my > sample is a powder mixture of carbon powder, MnO2 powder, and > potassium hydroxide liquid. The transmission coefficient of 6.5keV > x-rays (the Mn K edge is at ~6.5keV) through the sample is ~0.001 to > 0.01. I am told that the ionization chamber detectors can easily > detect the x-ray beam after this ~0.01 transmission loss (by > increasing the gain on the detector), but I would like to ask the > IFEFFIT community if there will be other problems with the EXAFS > technique when the transmission coefficient is so low. Does anybody > have comments? > > Much thanks -- if you have any info I greatly appreciate it! > Damon Turney > City College of New York > > > ------------------------------ > > Message: 2 > Date: Thu, 25 Jul 2013 13:33:12 -0700 > From: Matthew Marcus <mamarcus(a)lbl.gov> > To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> > Subject: Re: [Ifeffit] Is good EXAFS data possible with 0.01 > transmission coefficient > Message-ID: <51F18B88.5020600(a)lbl.gov> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Is most of the transmission loss due to the Mn or the matrix (C, KOH, etc)? Is that 0.01 above or below the edge? > If most of the absorption is due to the matrix with the Mn providing an edge jump of <1, then I'd say that you have a shot. > However, you become very sensitive to harmonics and glitches. If the Mn provides an edge jump of much less than 1, them fluorescence > would be the way to go, if possible. With thick samples in transmission, you have an issue with hole effect. For instance, it's > possible that your 1% transmission comes entirely from 1% area of pinholes, with the actual material being almost completely > opaque. If that happens, you get a reduced edge jump and reduced EXAFS amplitude, with distortions resembling overabsorption. > > If you're in the thick-matrix scenario, a possible workaround would be to make a sample which contains only matrix and is as nearly as > possible exactly as thick as the real sample, and measure its transmission, and subtract. > mam > > On 7/25/2013 1:07 PM, Damon Turney wrote: >> Hi IFEFFIT community, >> >> I will make measurements soon at Brookhaven's NSLS to do EXAFS, and my >> sample is a powder mixture of carbon powder, MnO2 powder, and >> potassium hydroxide liquid. The transmission coefficient of 6.5keV >> x-rays (the Mn K edge is at ~6.5keV) through the sample is ~0.001 to >> 0.01. I am told that the ionization chamber detectors can easily >> detect the x-ray beam after this ~0.01 transmission loss (by >> increasing the gain on the detector), but I would like to ask the >> IFEFFIT community if there will be other problems with the EXAFS >> technique when the transmission coefficient is so low. Does anybody >> have comments? >> >> Much thanks -- if you have any info I greatly appreciate it! >> Damon Turney >> City College of New York >> _______________________________________________ >> Ifeffit mailing list >> Ifeffit(a)millenia.cars.aps.anl.gov >> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit >> > > > ------------------------------ > > Message: 3 > Date: Thu, 25 Jul 2013 16:33:40 -0400 > From: Scott Calvin <scalvin(a)sarahlawrence.edu> > To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> > Subject: Re: [Ifeffit] Is good EXAFS data possible with 0.01 > transmission coefficient > Message-ID: <6A1D5E8E-88FB-4A0B-9CCC-9AF0CDB6623F(a)slc.edu> > Content-Type: text/plain; charset="us-ascii" > > Hi Damon, > > So you're saying you expect the total absorption of the sample to be less than 0.01 absorption lengths? In other words, if the detectors and electronics were identical, you would expect It = I0 exp(-0.01)? > > While possible to measure in transmission, such a sample would normally be measured in fluorescence. If done that way, the measurement is routine. > > Or am I misunderstanding your description? (I am not entirely sure what you mean by "transmission coefficient.") > > --Scott Calvin > Sarah Lawrence College > > On Jul 25, 2013, at 4:07 PM, Damon Turney <dturney(a)ccny.cuny.edu> wrote: > >> Hi IFEFFIT community, >> >> I will make measurements soon at Brookhaven's NSLS to do EXAFS, and my >> sample is a powder mixture of carbon powder, MnO2 powder, and >> potassium hydroxide liquid. The transmission coefficient of 6.5keV >> x-rays (the Mn K edge is at ~6.5keV) through the sample is ~0.001 to >> 0.01. I am told that the ionization chamber detectors can easily >> detect the x-ray beam after this ~0.01 transmission loss (by >> increasing the gain on the detector), but I would like to ask the >> IFEFFIT community if there will be other problems with the EXAFS >> technique when the transmission coefficient is so low. Does anybody >> have comments? >> >> Much thanks -- if you have any info I greatly appreciate it! >> Damon Turney >> City College of New York >> _______________________________________________ >> Ifeffit mailing list >> Ifeffit(a)millenia.cars.aps.anl.gov >> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > > > > ------------------------------ > > Message: 4 > Date: Thu, 25 Jul 2013 17:03:53 -0400 > From: Scott Calvin <scalvin(a)sarahlawrence.edu> > To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> > Subject: Re: [Ifeffit] Is good EXAFS data possible with 0.01 > transmission coefficient > Message-ID: <0830DFDB-C085-45F5-B434-B79DF12ABD72(a)slc.edu> > Content-Type: text/plain; charset="us-ascii" > > Oops--Matthew's interpretation is doubtless what you actually meant--i.e., that It < 0.01 I0. Therefore disregard my previous comment! > > And I concur with Matthew's comments, now that I understand the circumstances. > > --Scott Calvin > Sarah Lawrence College > > On Jul 25, 2013, at 4:33 PM, Matthew Marcus <mamarcus(a)lbl.gov> wrote: > >> Is most of the transmission loss due to the Mn or the matrix (C, KOH, etc)? Is that 0.01 above or below the edge? >> If most of the absorption is due to the matrix with the Mn providing an edge jump of <1, then I'd say that you have a shot. >> However, you become very sensitive to harmonics and glitches. If the Mn provides an edge jump of much less than 1, them fluorescence >> would be the way to go, if possible. With thick samples in transmission, you have an issue with hole effect. For instance, it's >> possible that your 1% transmission comes entirely from 1% area of pinholes, with the actual material being almost completely >> opaque. If that happens, you get a reduced edge jump and reduced EXAFS amplitude, with distortions resembling overabsorption. >> >> If you're in the thick-matrix scenario, a possible workaround would be to make a sample which contains only matrix and is as nearly as >> possible exactly as thick as the real sample, and measure its transmission, and subtract. >> mam >> >> On 7/25/2013 1:07 PM, Damon Turney wrote: >>> Hi IFEFFIT community, >>> >>> I will make measurements soon at Brookhaven's NSLS to do EXAFS, and my >>> sample is a powder mixture of carbon powder, MnO2 powder, and >>> potassium hydroxide liquid. The transmission coefficient of 6.5keV >>> x-rays (the Mn K edge is at ~6.5keV) through the sample is ~0.001 to >>> 0.01. I am told that the ionization chamber detectors can easily >>> detect the x-ray beam after this ~0.01 transmission loss (by >>> increasing the gain on the detector), but I would like to ask the >>> IFEFFIT community if there will be other problems with the EXAFS >>> technique when the transmission coefficient is so low. Does anybody >>> have comments? >>> >>> Much thanks -- if you have any info I greatly appreciate it! >>> Damon Turney >>> City College of New York >>> _______________________________________________ >>> Ifeffit mailing list >>> Ifeffit(a)millenia.cars.aps.anl.gov >>> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit >>> >> _______________________________________________ >> Ifeffit mailing list >> Ifeffit(a)millenia.cars.aps.anl.gov >> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > > > > ------------------------------ > > Message: 5 > Date: Thu, 25 Jul 2013 14:09:49 -0700 > From: Matthew Marcus <mamarcus(a)lbl.gov> > To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> > Subject: Re: [Ifeffit] Is good EXAFS data possible with 0.01 > transmission coefficient > Message-ID: <51F1941D.3010507(a)lbl.gov> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I'm pretty sure he has the opposite problem - the transmission is <0.01. That's assuming that "transmission coefficient" == "transmission". > mam > > On 7/25/2013 1:33 PM, Scott Calvin wrote: >> Hi Damon, >> >> So you're saying you expect the total absorption of the sample to be less than 0.01 absorption lengths? In other words, if the detectors and electronics were identical, you would expect It = I0 exp(-0.01)? >> >> While possible to measure in transmission, such a sample would normally be measured in fluorescence. If done that way, the measurement is routine. >> >> Or am I misunderstanding your description? (I am not entirely sure what you mean by "transmission coefficient.") >> >> --Scott Calvin >> Sarah Lawrence College >> >> On Jul 25, 2013, at 4:07 PM, Damon Turney <dturney(a)ccny.cuny.edu> wrote: >> >>> Hi IFEFFIT community, >>> >>> I will make measurements soon at Brookhaven's NSLS to do EXAFS, and my >>> sample is a powder mixture of carbon powder, MnO2 powder, and >>> potassium hydroxide liquid. The transmission coefficient of 6.5keV >>> x-rays (the Mn K edge is at ~6.5keV) through the sample is ~0.001 to >>> 0.01. I am told that the ionization chamber detectors can easily >>> detect the x-ray beam after this ~0.01 transmission loss (by >>> increasing the gain on the detector), but I would like to ask the >>> IFEFFIT community if there will be other problems with the EXAFS >>> technique when the transmission coefficient is so low. Does anybody >>> have comments? >>> >>> Much thanks -- if you have any info I greatly appreciate it! >>> Damon Turney >>> City College of New York >>> _______________________________________________ >>> Ifeffit mailing list >>> Ifeffit(a)millenia.cars.aps.anl.gov >>> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit >> >> >> _______________________________________________ >> Ifeffit mailing list >> Ifeffit(a)millenia.cars.aps.anl.gov >> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit >> > > > ------------------------------ > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > > End of Ifeffit Digest, Vol 125, Issue 14 > ****************************************

4 3

Is good EXAFS data possible with 0.01 transmission coefficient
by Damon Turney 25 Jul '13

25 Jul '13

Hi IFEFFIT community, I will make measurements soon at Brookhaven's NSLS to do EXAFS, and my sample is a powder mixture of carbon powder, MnO2 powder, and potassium hydroxide liquid. The transmission coefficient of 6.5keV x-rays (the Mn K edge is at ~6.5keV) through the sample is ~0.001 to 0.01. I am told that the ionization chamber detectors can easily detect the x-ray beam after this ~0.01 transmission loss (by increasing the gain on the detector), but I would like to ask the IFEFFIT community if there will be other problems with the EXAFS technique when the transmission coefficient is so low. Does anybody have comments? Much thanks -- if you have any info I greatly appreciate it! Damon Turney City College of New York

3 4

Artemis in Demeter 0.9.17 Crashing Upon Loading Project File
by Anthony Ardizzi 17 Jul '13

17 Jul '13

Dear Bruce and Ifeffit mailing list, I have just started experiencing a program crash in Artemis while trying to load a project I am working on. I am performing a fit on Sr2IrO4 data, and when I try to open the project file, it starts loading all of the usual stuff, and then when it gets to loading the path-lists/data sets screen for one of the two data sets I have, the entire program simply closes. I have attached both my project file, as well as the dartemis log file. I believe the relevant error in the log file is "Illegal division by zero at C:/strawberry/perl/site/lib/Demeter/Data.pm line 922." I am running Windows 7 64-bit. Thanks for any help you can provide, Anthony

3 4

Artemis Autosave Files
by Shoaib Muhammad 16 Jul '13

16 Jul '13

Hi, I am using Demeter 0.9.17, and trying to fit in-situ XAFS data of metal oxides and it is going well other than these minor problems on my Windows 7 PC. A couple of times "Feff" module in Artemis stopped responding and I had to force close the program. Now whenever I click on .fpj files I see a window which asks me to restore from previous autosave files. I click "Cancel" this dialogue box disappears but selected .fpj file is not automatically loaded. Next time when I try to open another .fpj file, I get the same window and behavior again. Is there any way to delete these autosave file? I have searched in mail archieve but there is no querry regarding it for this "Demeter" version. Since I have a bunch of Artemis fits on my PC, to save time I select "File" and then "Close" to close the current fit and then open another Artemis fit instead of "File" and "Exit". In this way when I open another Artemis fit (.fpj) file, I see a couple of "Feff Calculations" in the main Artemis tool bar. How ever I usually don't see these many 'Feff Calculations" if I completely close the Artemis and then reopen the same file. Is there any way to solve this behavior? Screen shots of both the problems are attached. Thanks, -- Shoaib M. Department of Energy Science Sungkyunkwan University South Korea

2 1

Re: [Ifeffit] Ifeffit Digest, Vol 125, Issue 5
by Abhijeet Gaur 14 Jul '13

14 Jul '13

Hi Paul, I think that this research article on Fe K-edge by Westre et al. (1997) will help you in the analysis of your samples. With regards -- Dr. Abhijeet Gaur

1 0

XANES pre-edge peak intensities
by Bingham, Paul A 14 Jul '13

14 Jul '13

Dear Ifeffit forum users I have been working on a batch of Fe K-edge XANES data for dilute glasses some time and I have extracted pre-edge peak positions and intensities, as has been widely used in the literature, to get qualitative analysis of the Fe coordination in my samples. I have also done this for a number of mineral "standards", again as has widely been done in the literature (Grandidierite, Yoderite, Staurolite, etc). However, I have a question: as my samples are considerably more dilute (ca. 0.15 mol% Fe) than all of the mineral standards (these vary in Fe content between a few percent and 10's of percent), how realistic is it to use mineral standards such as these to provide reference points to "calibrate" the integrated pre-peak intensities from the dilute samples? I have found nothing conclusive on this in the literature and would ask this forum for help, or any thoughts you may have on this issue. My own feeling is that concentration will have an effect on integrated pre-edge intensities and I suspect that more dilute samples are likely to give slightly higher integrated intensities than concentrated samples, but it is difficult to unpick and any thoughts or useful references dealing with such issues would be most welcome. Many thanks in advance for taking the time to read this message and thanks for your responses! Kind Regards Paul Bingham

5 4

Basic EXAFS question
by Darren Dale 13 Jul '13

13 Jul '13

Hello All, If I have a Ta(1-x)Ge(x)O(y) thin film, with Germanium concentration of a few percent, is it possible in principle to get useable fluorescence-mode EXAFS spectra around the Ge K edge (11.1 keV)? Or is it likely that the spectra would be complicated by additional Ge fluorescence excited by processes triggered by Tantalum L edge absorption (9.88, 11.13, 11.68 keV)? Thanks, Darren

5 4

User interface question for Demeter
by Scott Calvin 08 Jul '13

08 Jul '13

Hi Bruce, I and my group have finally started using Demeter Artemis, and in general it's wonderful. But there's one aspect of the user interface philosophy that I'm either not getting or finding clunky. In Horae, it was sometimes possible to rearrange the order of lists. For example, the list of groups in Athena could be rearranged by moving groups up and down, while the list of parameters in the GDS screen could be rearranged by using the "move" option. I'm not really finding that functionality in Demeter. The GDS screen does allow copying, but that requires a multiple-step process for a move. And I don't see a way to rearrange the order of groups in Athena at all. In addition, there's a new place where this kind of functionality would be helpful but appears to be lacking: the path list in the Data window. Since that list is now populated by drag-and-drop, it can end up in some pretty oddball orders. Am I just not grokking some UI feature that lets the user rearrange the order of lists? Dragging, for instance, doesn't seem to work. Or are there other features I should be using that make the order of those lists relatively unimportant? Or is ordering lists something that will appear in future versions, but it just hasn't been implemented yet? If the latter, then I also have a further feature suggestion, although it's not high priority. It would be quite useful if the path list in the Data window could be sorted in various ways, perhaps even with primary and secondary criteria. So, for example, sort by feff calculation, and then by importance. Or by number of legs, and then by Reff. While the marks menu lets us quickly select paths in a number of nifty ways, getting them in order of Reff or importance would be quite effective at cleaning up messy lists. --Scott Calvin Sarah Lawrence College

6 9

Unable to import data from HXMA beamline at CLS into Athena
by Anthony Ardizzi 26 Jun '13

26 Jun '13

Hello, I am currently at the HXMA beamline at the CLS facility in Saskatoon, Canada. I have attempted to import some of the data we have taken here into Athena (demeter version 0.9.17), however I continue to receive the following error: "C:\...\xxxxx.dat could not be read as data". I suspect that this might be a problem with the latest demeter release, as an associate of mine seems to have no problem importing these data files into Athena 0.8.056. I have attached a .dat file so that you can verify that the formatting is readable by Athena. Hopefully someone can provide some help. I would prefer not to have to go back to an older version of Athena if possible. Also, I am running Windows 7 64-bit, in case that is relevant Thanks in advance, Anthony

3 4

Disable duplicate data group check
by Jason Gaudet 21 Jun '13

21 Jun '13

Hi all, Not a bug this time, but a feature that occasionally frustrates me. Artemis does a sanity check prior to fitting, and if it detects a project has two instances of the same Athena data group, it will refuse to fit the new data. IME this is not a particularly helpful warning, and a major hassle if I'm trying a couple different treatments of the same data to see how the FEFF fit is affected. (The message is "This data came from the the same source as another data group. You seem to be trying to increase your number of independent points by fitting the same data more than once in a multiple data set fit." But of course I'm not doing this; only one dupe is being fitted at a time.) I don't see any option in the Artemis preferences to disable this warning, which means I have to spend effort deleting and loading data sets, and keeping a "dummy" data set I don't really care about to collect all my paths in. Is the possibility of extremely novice users trying to fit multiple instances of the same data such a serious threat that this function needs to exist? Is there any possibility of disabling this check, or giving an option to disable it in the Preferences? It would save me from the occasional headache ... Thanks, Jason

3 2

bond angle
by washington gomes 21 Jun '13

21 Jun '13

Dear Colleagues, I am structure characterized of La0.8Ba0.2CoO3 by x-ray spectroscopy, used program IFFEFIT 1.2. 10. I wonderif it is possible to determine the bond angle Co-O-CO,used IFFEFIT code in the extended x -ray absorption fine structure EXAFS. If possible, I would like you to indicate the material that shows examples of how to determine the bond angle Co-O-CO. Sincerely yours, Wahington

2 1

Re: [Ifeffit] no so2 term in Artemis
by Bruce Ravel 14 Jun '13

14 Jun '13

On 06/14/2013 02:59 AM, Lei Cheng wrote: > Dear Dr. Bruce Ravel, > > My name is Lei Cheng, I am a graduate student in UC-Berkeley and doing > my research in LBNL. > > I started to learn how to use Demeter for data processing and fitting. I > got this very bizarre problem with Artemis (please see the attached > screen shot). The so2 term is not showing up. (For your information, I > tried with two different computers, Win 7 64-bit, Win 8 64-bit, Demeter > version 0.9.17 and 0.9.13, Demeter is installed in E:\strawberry\ or > C:\strawberry\) > > Thanks for your time and looking forward to your reply > > -Lei Lei, The Ifeffit mailing list exists to handle questions like this one. I am CCing my reply to the mailing list. Please subscribe to and use the mailing list for any follow-up to this issue. Here is information about the list: http://cars9.uchicago.edu/mailman/listinfo/ifeffit/ If I understand your issue, it is a fairly minor one. The label that says "S02" is not being displayed, but otherwise Artemis works as expected. Is that correct? Are you able to perform fits with Artemis? Are you able to access the context menu (normally, one would right click on that label -- see about halfway down this page: http://bruceravel.github.io/demeter/artug/path/mathexp.html)? I have not observed this behavior on any of my windows machines nor on those of any of the folks who visit my beamline. So I am not sure how to proceed. I am suspicious that this is a locale issue, that is, an issue with how fonts and unicode characters are displayed on your machine. Your name suggests that you may be Chinese. Do you have your computers configured to display something other than English? In applications like Word or Explorer, are the menus and buttons labeled in English or some other language? The reason I ask is that it is possible that I have never observed this problem because none of my computers are configured to display an eastern language. B -- Bruce Ravel ------------------------------------ bravel(a)bnl.gov National Institute of Standards and Technology Synchrotron Methods Group at NSLS --- Beamlines U7A, X24A, X23A2 Building 535A Upton NY, 11973 Homepage: http://xafs.org/BruceRavel Software: https://github.com/bruceravel

1 0

Athena Deglitch Problem
by George Sterbinsky 11 Jun '13

11 Jun '13

Hello, I am writing to report what I believe to be two bugs in Athena 0.9.17. In the attached project file, attempting to use the Deglitch feature to remove the point at ~816 eV (the obvious glitch) returns the attached error message and does not remove the point. Also, when selecting "linespoints" for the "datastyle" in the gnuplot preferences, the data continues to be plotted as lines only. Thank you, George

2 1

Re: [Ifeffit] Very large exafs amplitude in collected data - cause unknown (Jason Alvino)
by Jason F. Alvino 10 Jun '13

10 Jun '13

Hi Matt, As I pointed out before, in the attached zipfile, there is a file called "AuNP_anatase_Au.D" which has the data in two columns of energy vs mu, comma separated underneath the "EV RAW" header. It also already has all the bad channels removed from the averaged data. Cheers, Jason Hi Jason, > > On Fri, Jun 7, 2013 at 9:25 AM, Jason F. Alvino > <jason.alvino(a)adelaide.edu.au> wrote: > > Hi all, > > > > There seemed to have been abit of a misunderstanding with the data > format, > > sorry about that. I was not really sure what format was going to be best > to > > share with people, I thought the raw data would have been useful so that > > people were able to see all the channels. > > > > I have attached a data file from average (AuNP_anatase_Au.D) which has > the > > data in columns of energy vs u(E). > > > > The second data format (.ssrl) has data in the following columns; > > > > 1 = real time clock > > 2 = Mono angle (requested) > > 3 = Energy (eV) > > 4 = I0 > > 5 = I1 > > 6 = I2 > > 7-9 = blank > > 10-44 - fluor channels (SCA) > > 45-79 - ICRs for the det element > > > > I have attached these two data sets to this new email. > > I still am completely unwilling to work with that file. Send a file > with no more than 5 columns, and do not expect anyone to add columns > together or know how you would use the different columns in your file. > It's best to send a file with only energy and xmu. > > > Now to try to answer some of the questions that have been asked of the > data. > > > > The samples are chemically synthesised Au8, Au9, Au11 clusters protected > by > > PPh3 ligands. We then support these samples on various oxides, in this > case > > anatase at a % weight loading of 0.17% cluster/anatase. The loading is > > typically quite low as we discovered that higher loadings lead to greater > > levels of Au agglomeration. The samples can then undergo various > treatments, > > in an attempt to remove the protective ligand groups, however harsher > > treatments can also lead to agglomeration of the Au clusters. The > currently > > attached example is of Au9 on anatase at 0.17% loading after being > calcined > > at 200 C under an oxygen atmosphere. There was potentially an issue > > initially about releasing all the info of the samples which has now been > > sorted out. > > > > "Perhaps there is some sort of coupling in the signal chain between the > Ge > > detector and IO" - I wouldn't really know how to start with that one, > > however I could have another chat with the beamline scientists over this > and > > see if they may have some ideas as to the cause. > > > > We were actually analysing some of the data as we went, but unfortunately > > not all of it. However this problem of large k2 or k3 weighted exafs > > amplitude only occurs in samples that we know begin to agglomerate into > > larger particles of gold (this has been determined from a similar study > we > > have done at the SXR). We have multiple samples that display this > behaviour. > > > > The values I get for sigma2 when trying to fit using XFIT are 2 or > greater, > > if I maintain debye waller factors greater than 0.001 and maintain > sensible > > coordination numbers <=12. > > > > The samples were cooled to 12 K using a cryostat, however the Au foil > data > > is not cooled. > > That alone could explain the difference. > > > --Matt > > > ------------------------------ > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > > End of Ifeffit Digest, Vol 124, Issue 8 > *************************************** > -- Jason F. Alvino PhD Candidate (Chemistry) School of Chemistry and Physics University of Adelaide, AUSTRALIA 5005 Ph : +61 8 8313 3707 E-mail: jason.alvino(a)adelaide.edu.au

2 1

Re: [Ifeffit] Very large exafs amplitude in collected data - cause unknown (Jason Alvino)
by Jason F. Alvino 07 Jun '13

07 Jun '13

Hi all, There seemed to have been abit of a misunderstanding with the data format, sorry about that. I was not really sure what format was going to be best to share with people, I thought the raw data would have been useful so that people were able to see all the channels. I have attached a data file from average (AuNP_anatase_Au.D) which has the data in columns of energy vs u(E). The second data format (.ssrl) has data in the following columns; 1 = real time clock 2 = Mono angle (requested) 3 = Energy (eV) 4 = I0 5 = I1 6 = I2 7-9 = blank 10-44 - fluor channels (SCA) 45-79 - ICRs for the det element I have attached these two data sets to this new email. Now to try to answer some of the questions that have been asked of the data. The samples are chemically synthesised Au8, Au9, Au11 clusters protected by PPh3 ligands. We then support these samples on various oxides, in this case anatase at a % weight loading of 0.17% cluster/anatase. The loading is typically quite low as we discovered that higher loadings lead to greater levels of Au agglomeration. The samples can then undergo various treatments, in an attempt to remove the protective ligand groups, however harsher treatments can also lead to agglomeration of the Au clusters. The currently attached example is of Au9 on anatase at 0.17% loading after being calcined at 200 C under an oxygen atmosphere. There was potentially an issue initially about releasing all the info of the samples which has now been sorted out. "Perhaps there is some sort of coupling in the signal chain between the Ge detector and IO" - I wouldn't really know how to start with that one, however I could have another chat with the beamline scientists over this and see if they may have some ideas as to the cause. We were actually analysing some of the data as we went, but unfortunately not all of it. However this problem of large k2 or k3 weighted exafs amplitude only occurs in samples that we know begin to agglomerate into larger particles of gold (this has been determined from a similar study we have done at the SXR). We have multiple samples that display this behaviour. The values I get for sigma2 when trying to fit using XFIT are 2 or greater, if I maintain debye waller factors greater than 0.001 and maintain sensible coordination numbers <=12. The samples were cooled to 12 K using a cryostat, however the Au foil data is not cooled. Also it seems my first response email directly replied to Bruce, sorry about that I simply hit the reply button on the forum page instead of writing a new email to the mailing list. I had attached a data file from average (AuNP_anatase_Au.average) which had the data in columns of energy vs u(E), to Bruce, which may have been overlooked. If anything needs further clarification please let me know. As I'm sure you are already aware this was only our first trip using XAFS so our experience is quite limited. Cheers for all the input so far! Jason

2 1

Re: [Ifeffit] Very large exafs amplitude in collected data - cause unknown
by Bruce Ravel 05 Jun '13

05 Jun '13

On Wednesday, June 05, 2013 02:55:25 PM you wrote: > Hi, > > Sorry about that, I wasn't sure what the best format would be for these > forums. I have converted the data to a different format that should > hopefully be more friendly. > > This has data in the following columns; > > 1 = real time clock > 2 = Mono angle (requested) > 3 = Energy (eV) > 4 = I0 > 5 = I1 > 6 = I2 > 7-9 = blank > 10-44 - fluor channels (SCA) > 45-79 - ICRs for the det elements > > The weights are arbitrarily unity, and the dark currents were not recorded > (assumed zero). > > I have also attached an averaged file generated using average 2.0 if thats > more useful for people. Jason, You replaced one large, unweildy file format with another large, unwieldy file format. You should consider yourself fortunate that I have taken the time to bother with you. The folks on this mailing list, myself included, are volunteers. None of us get anything for offering time to answer these questions other than a sense of community spirit and community service. It is completely unreasonable that you have asked your question in a way that required lots of work simply to understand the question. Had you been a little more thoughtful and a little less unreasonably demanding of the time of volunteer help, you could have converted your data files into simple, 2-column files -- energy and mu(E) -- that would have been trivially easy for your volunteer to examine. Instead, you first sent the data in one basically inscrutable format, then in a second similarly unwieldy format. Awesome. Such a good use of my time. Please read this: http://bruceravel.github.io/demeter/pods/help.pod.html When you are done, please follow the link to the article by Raymond and Moen and read that. Now that I've had my rant, I'll address your question. Attached is your Au nanoparticle data overplotted with a spectrum measured on a gold foil. Clearly your data is awful and probably unsalvageable. Without knowing all the details of your measurement, it is very difficult to know what went wrong. Given that the oscillations in your data are commensurate with those in the gold foil, it is unlikely to be a monochromator problem or a problem with pressure variations in the I0 ionization chamber. I also don't think you had an egregious problem with sample preparation. Problems that fall under the rubric of sample inhomogeneity tend to damp the oscillations rather than enhance them. Also sample inhomogeneity tends to fail to normalize mono glitches away. You data, while problematic, don't seem to have that problem. My guess is that you have a problem of detector linearity, but not saturation of the Ge detector. Saturation (aka pile-up, dead-time) also serves to damp the oscillations. Perhaps there is some sort of coupling in the signal chain between the Ge detector and I0? I'm knd of running out of ideas here.... The bottom line is that this is the sort of problem that needs to be recognized and addressed while still at the synchrotron. I don't see what you can do to correct this after the fact in a way that would leave your data defensible for publication. The slim silver lining is that this teaches an important lesson about evaluating data quality as it is being measured. B -- Bruce Ravel ------------------------------------ bravel(a)bnl.gov National Institute of Standards and Technology Synchrotron Methods Group at NSLS --- Beamlines U7A, X24A, X23A2 Building 535A Upton NY, 11973 Homepage: http://xafs.org/BruceRavel Software: https://github.com/bruceravel

3 3

Very large exafs amplitude in collected data - cause unknown
by Jason F. Alvino 04 Jun '13

04 Jun '13

Hi, We have collected fluorescence data of PPh3 protected Au nanoparticles supported on an anatase surface at the Au L3 edge, which provides some decent looking exafs and seems to fit a bulk gold model rather well (there seems to be agglomeration on the surface, even with our low loadings). We have tried to fit the data using both XFIT and EXAFSPAK, but the strange thing is that the exafs oscillations have a huge amplitude, up to 80 in some cases. Because of this, the only way to fit the data while maintaining sensible Debye-Waller factors is to allow SO2 to become quite large, or to allow the coordination numbers to become very large. We have spoken to a few others in the field and they have yet to be able to rationalize why there is such a large signal. I have attached an example of one of the data sets with very large amplitude, if anyone would be willing to take a look at the data it would be much appreciated. Cheers, Jason -- Jason F. Alvino PhD Candidate (Chemistry) School of Chemistry and Physics University of Adelaide, AUSTRALIA 5005 Ph : +61 8 8313 3707 E-mail: jason.alvino(a)adelaide.edu.au

2 1

Possible bug - dathena does not work on XP mode
by ASAKURA, Hiroyuki 01 Jun '13

01 Jun '13

Dear list, I am trying to use dathena, dartemis and dhephaestus in Demeter 0.9.17 package on Windows XP ("XP mode" on Windows 7), but neither Athena nor Artemis nor Hephaestus works. On Windows 7 (both 32 bit and 64 bit), everything works. The symptoms are similar to the latest post's, the command prompt and the splash screen appears momentarily, disappears, and then nothing happens. In contrast, (stand-alone) Atoms opens. Reinstallation of Demeter does not solve this booting problem. I checked MinGW and demeter.mru problems reported on this ML, but there are no other MinGW installation or corrupted detemer.mru. OS: Windows XP on Virtual PC ("XP mode" on Windows 7 32 bit) (Japanese version) (All updates are applied.) Demeter: 0.9.17 (on standard path C:\strawberry...) (ver. 0.9.13.1 also does not work.) In addition, I've heard that this phenomenon happens at least on Windows XP in many other real machines. (not on virtual machines) Any suggestions would be appreciated. Best regards, ASAKURA, Hiroyuki -- ASAKURA, Hiroyuki Designated Research Associate Synchrotron Radiation Research Center, Nagoya University, Japan h.asakura(a)nusr.nagoya-u.ac.jp

2 3

Bug Report - (D)Athena Doesn't Open
by Rodriguez, Roberto 29 May '13

29 May '13

I'm currently having trouble opening both (D)Athena and (D)Artemis. When I first installed Demeter a couple months ago, the programs worked properly without any issue until recently. In both cases, the command prompt and the splash screen appear momentarily, disappears, and then nothing happens - the program never opens. To my knowledge, no settings have been changed that would prevent Athena/Artemis from opening. In contrast, (D)Hephaestus and (D)Atoms open and appear to function properly. I've tried uninstalling/reinstalling Demeter 0.9.13.1 in addition to installing the Updater 0.9.17, but I keep having the same issue. Any suggestions would be most helpful. Operating system is Windows 7 Enterprise. Regards, Roberto Roberto Rodriguez Development Engineer UOP LLC, A Honeywell Company 25 E Algonquin Rd., Des Plaines, IL 60017 Office: Bldg. 2, 350-B Office Phone: (847)391-2582 Cell: (815) 351-4481 Email: Roberto.Rodriguez(a)uop.com<mailto:Roberto.Rodriguez@uop.com>

3 2

closing Artemis project
by Christopher Patridge 28 May '13

28 May '13

Hello, I have a question about (D)Artemis. After saving a project, I used the Close option under File. This does remove the datasets and feff calculations but it keeps the name of the project in main window header. Is there a way to begin a new project other than closing Artemis and/or beginning a project and use the save as option? One other thing, is there any possibility of extending the number of datasets for artemis? Thanks, Chris Patridge -- ******************************** Christopher J. Patridge, PhD NRC Post Doctoral Research Associate Naval Research Laboratory Washington, DC 20375 Cell: 315-529-0501

2 1

Demeter 0.9.17
by Bruce Ravel 28 May '13

28 May '13

Hi, I just uploaded a new Windows updater package for Demeter and tagged version 0.9.17 at GitHub. This release introduces no new features but fixes the handful of problems reported in recent weeks. The updater package can be obtained at Demeter's homepage: http://bruceravel.github.io/demeter/ Cheers, B -- Bruce Ravel ------------------------------------ bravel(a)bnl.gov National Institute of Standards and Technology Synchrotron Methods Group at NSLS --- Beamlines U7A, X24A, X23A2 Building 535A Upton NY, 11973 Homepage: http://xafs.org/BruceRavel Software: https://github.com/bruceravel

1 0

Opening XANES Files with Athena
by Alex Kellum 24 May '13

24 May '13

Hello All, I am working on an NSF-REU program this summer requiring me to analyze XANES spectra. My personal computer is a mac (w/ OS X 10.6.8). I am desperately trying to figure out how to even open an IFEFFIT program that will help me analyze the spectra. The spectra are saved in .txt files--and I have no idea how to convert them to .apj or .prj files. Is it possible to analyze them with converting them? Right now I am using iXAFS Shell containing Athena, Artemis and Hephaestus. I realize there are newer versions available, but Demeter is only available on Windows and I spent a few hours trying to get Larch to work. Even after downloading python I had no idea how to get it to actually download and work. I do have X11 running on my computer. I realize you probably get a ton of emails from users, but any help would be greatly appreciated. Regards, Alex Kellum

3 2

Correction to radial distance
by Francisco Garcia 24 May '13

24 May '13

Dear all, Can an experienced user kindly explain how to obtain the phase shift correction to the radial distance corresponding to FFT(chi(k)). From my chi(k) computation, I have several feff*.dat files (feff0001.dat, feff0002.dat,...............,feff00128.dat) because I have 128 paths. How do I use this information and IFEFFIT to compute the shifted spectrum? Thank you.

2 1

JFEFF/FEFF9 "Save&Run" no longer works after Java Update -- FEFFgroup announcement
by Kevin Jorissen 16 May '13

16 May '13

Dear iFEFFIT community, a short update from the FEFF developers team: A recent Java update (Java 7 Update 21) broke some functionality of the JFEFF interface for the FEFF program. Users who update to J7U21 have noticed that when they click "Save&Run" nothing happens: the FEFF programs do not run and there is no output. We think this issue will affect people on all Operating Systems. To fix this issue there are two possibilities: * Roll back Java to a previous version. For security reasons please have at least Java 7 Update 11, which was an important security update, or newer. Instructions for rolling back Java can be found online. * We have updated JFEFF to work with the latest Java. This latest (J)FEFF version is not yet available on the official download website, but FEFF users with a valid license can contact us and we will provide them with a download link for the latest (J)FEFF. Please contact us directly. Users who currently have FEFF8 can upgrade to FEFF9 at any time at a discounted rate. Thank you to Linda Lim for her earlier post on the iFEFFIT ML. Cheers, Kevin Jorissen FEFFgroup - University of Washington

1 0

normalization methods
by Matt Newville 16 May '13

16 May '13

Hi Folks, Over on the github pages for larch, Mauro and Bruce raised an issue about the "flattening" in Athena. See https://github.com/xraypy/xraylarch/issues/44 I've added a "flattened output" from Larch's pre_edge() function, but the question has been raised of whether this is "better" than the simpler normalized spectra, especially for doing PCA and/or LCF for XANES. Currently, the "normalized" spectra is just "(mu - pre_edge_line)/edge_step". Clearly, a line fitted to the pre-edge of the spectra is not sufficient to remove all instrumental backgrounds. In some sense, flattening attempts to do a better job, fitting the post-edge spectra to a quadratic function. As Mauro, Bruce, and Carmelo have pointed out, it is less clear that it is actually better for XANES analysis. I think the main concerns are that a) it is so spectra-specific, and b) it turns on at E0 with a step function. Bruce suggested doing something more like MBACK or Ifeffit's bkg_cl(). It would certainly be possible to do some sort of "flattening" so that mu follows the expected energy dependence from tabularized mu(E). Does anyone else have suggestions, opinions, etc? Feel free to give them here or at the github page.... --Matt

3 12