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

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