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

DORIS III operation ended
by Edmund Welter 23 Oct '12

23 Oct '12

Dear fellow XAFS user, yesterday (October 22^nd 2012, 8 am) the DORIS III storage ring in Hamburg was switched of for good. That means our 3 EXAFS beamlines are left without photons and user operation at these beamlines had to end. In the next 2 years we will build 2 new EXAFS beamlines at the PETRA III storage ring that will hopefully equally well serve the demands of our large user community as the 3 closed beamlines did during the last 20+ years. I know this mailing list is mainly about software and number crunching, but I thought the end of operation of a machine that produced so many beautiful numbers to be crunched with IFEFFIT/Athena/Artemis etc. might justify a short notice on this list. Anyway, to close the circle to the software, the end of user operation of HASYLAB's DORIS beamlines finally gives our users the chance to use this software and produce many nice papers during the coming months (Ah,wait, that was something different, New York, July 1977 :-). I am looking forward to see you all back at our PETRA extension beamlines in autumn 2014! Let me close this mail with the last line of data ever measured at the A1 EXAFS beamline: 7893.277 0 0 0 0 0 0 0 0 0 0 0 0 0 5.489 13.22 Best regards, Edmund Welter -- -------------------------------------------------------- Dr. Edmund Welter Deutsches Elektronen-Synchrotron DESY FS-Do Notkestr. 85 Email: edmund.welter(a)desy.de D-22607 Hamburg Phone: +49 40 8998 4510 Germany Fax : +49 40 8998 2787 --------------------------------------------------------

2 1

release 0.9.13.1
by Bruce Ravel 22 Oct '12

22 Oct '12

Hi, As a result of a problem brought to my attention by Ku-Ding Tsuei, I built a new installer of my software for Windows. The new installer, release 0.9.13.1 can now be downloaded from http://bruceravel.github.com/demeter/ This is an installer package. There is not a package for updating from 0.9.12. You must download and install the new installer package. This new installer is essential for anyone using Artemis. As Ku-Ding discovered, versions 0.9.11 through 0.9.13 all suffer from the same problem. If you are using Artemis from any of the affected versions, you *must* upgrade. I apologize for making three flawed releases of my software and I hope that no one has been too inconvenienced by my mistake. Once again, this mailing list and its most excellent community proves to be the best feature of our software! As a bit of consolation, I want to direct your attention to the Artemis Users' Guide. I have put a lot of effort into it in recent weeks. It is still not complete, but it is much enhanced. http://bruceravel.github.com/demeter/artug/index.html Regards, 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

Running (D)Artemis yields different result from that shown in (D)Artemis instruction videos
by Tsuei, Ku-Ding 21 Oct '12

21 Oct '12

Hi Bruce, I went through your (D)Artemis instruction videos and ran the latest Demetris 0.9.12 with 0.9.13 update side by side to reproduce the results. However, my running yields much poorer fitting results on Au foil EXAFS, even the first shell (video 03). Actually it happened using the older 0.9.11 too. I also went through your Lecture videos shot at Diamond and ran (D)Artemis but could reproduce your results closely. I have felt puzzled for quite a while why the simplest case Au foil does work well. Today I tried to run the same Au data and fitting by the old, last version of Artemis 0.8.014. I could produce very good fitting on the first shell with the R-factor very near that shown in the video. I made sure the math expressions for the fitting parameters amp, enot, delr and ss are set exactly the same, with fitting range exactly the same, in both programs. Their screen outputs file is attached. The saved respective project files are also attached. I copied the fit outputs into their journals. I would appreciate if you may review these results and help clear my puzzle. Best regards, Ku-Ding

2 1

feff800 path files
by Maria Zougrou 18 Oct '12

18 Oct '12

Hi, I'm trying to construct the heulandite structure running atoms and feff800 for the 3 Ca sites. Atoms gives me a feff8.inp I got the paths for Ca1 site, but it doesn't calculate the Ca2 paths. There doesn't seem to be a geometry problem, I don't get a message that some atoms are too close, what could be the problem? I'm attaching the files I'm using. Thank you

2 1

possible bug: same Artemis project file, different results on 2 PCs
by Jeremy Thorbahn 10 Oct '12

10 Oct '12

Hi Bruce, I was putting together another post for the list (which is currently awaiting moderation since apparently my attached project files were too large) when I encountered some strange behaviour in Artemis. I tried opening my project file on my second PC to check that it would open fine for other members of the list. But by simply opening the project and clicking Fit, I was getting different results for my guess parameters on the two PCs. Both PCs are Windows 7 and updated to Demeter 0.9.13. Here is a link to the project file (trying to avoid size limitations for the list this time) http://dl.dropbox.com/u/10663174/ZnO.fpj and I will attach a screenshot of Artemis demonstrating what I am talking about from my two PCs. Since I am working to determine S02 and it is very different on each PC, I am hesitant to trust any of my results right now. Thanks Jeremy --

2 2

determining S02 from ZnO vs. Zn foil
by Jeremy Thorbahn 09 Oct '12

09 Oct '12

[note: when putting together this post I discovered a possible bug regarding opening my project files on different PCs. I will submit that issue separately] Hi all: I am writing to probe the community's knowledge regarding my current problem in measuring S02. I have data on a series of glass samples containing ZnO. I also measured a ZnO crystalline powder, and a Zn foil was measured between detectors 2 and 3 (transmission mode) simultaneously with every run. My goal is to determine coordination numbers around Zn in the glass samples, which requires an accurate measurement of S02 for zinc. My main question is if there is any reason why the Zn foil would provide a more accurate result than the ZnO powder, or vice versa. I see no reason why it should be different, especially since this method depends entirely on the 'chemical transferability' of S02 in the first place. Nevertheless, I obtain different results from each, with S02 ~ 0.75 from the ZnO and ~0.88 from the foil. Statistically, the Zn foil dataset is "better" since it is a merge of all of my scans while there are only two scans of ZnO. However, part of me wants to trust the ZnO data more, for somewhat vague reasons such as that it is a "more similar" coordination environment to what I would expect in my samples, and that it was measured between the same two detectors, etc. If anyone has any experience that would indicate why one should be better than the other, I would love to hear about it. I will attach Artemis project files for each if you'd like to take a look at my fits. It is entirely possible that the discrepancy is due to an error in data processing or analysis on my part; I am by no means an expert. I hope the project files will not clog up anyone's mailbox, at a couple of megabytes each. Thanks, Jeremy

3 3

Atoms bug & Athena request
by Bruce Ravel 04 Oct '12

04 Oct '12

Fred: Thanks for the bug report. It was a simple fix and I even uncovered another mistake in how crystal data that is entered by hand gets interpreted. Cool! Bradley: You'll be putin' on your dancing shoes after the next release. The combinatorial output files will be named as you requested. As always, thanks for the feedback. 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

possible minor bug in atoms in artemis probably just me
by fred.mosselmans＠diamond.ac.uk 04 Oct '12

04 Oct '12

Hi Bruce et al. I searched the mailing list for something similar as i feel this is so obvious it must be there to find. However i could n't find it so ... Also there's are easy workable workarounds so it's not very important. I was XAS data for atoms that sit in substituted sites in a known lattices - Sr in calcite, If i build the calcite lattice in atoms stand alone and save output from there and read into artemis then substitute Sr for Ca before running Feff etc. And import to Artemis the world is lovely (viewed on the perspective does the program continue working perspective and no wider one.) If i try to either read my Sr prj and then do the same (i.e. typing the xtal paras in) within artemis or just try to do that before reading in the Sr data the program crashes as soon as i try to run atoms. The log file error line is: Can't call method "element" without a package or object reference at C:/strawberry/perl/site/lib/Demeter/Atoms/Absorption.pm line 31. If i read the saved atoms input file (from stand-alone) into Demeter it runs fine. So i guess something is set up when i save it in stand alone atoms that ain't inputted by me and that helps out. Maybe this is meant to happen as people are supposed to read in cif files and the like and for slow people like myself who enter things by hand there are obstacles left strewn on the road. Fred The atoms inp file is attached. This works however entering these same xtal paras by hand doesn't if it's my hand(s) There are more recent calcite lattice paras but that doesn't affect the process. -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

1 0

D-Athena Request
by BradleyW Miller 03 Oct '12

03 Oct '12

Hi, A minor (I hope) request for D-Athena on PC's. When running a LCF (eg collected a spectrum and named it AsScan1) and exporting the LCF predicted results to an excel file, the default name of the newly created xls file is "combinatorial.xls". In Athena (on PC) the default output file name was the name of the spectra you are fitting (eg AsScan1.cvs). If the default in D-Athena could be the name of the original spectra again that would be very appreciated. If it could be the name of the spectra and the name of the fit space (eg. AsScan1.derv.xls or AsScan1.norm.xls or AsScan1.Chi.xls)... I may have to dance a jig in your honor. Thanks for your time and the freeware. Respectfully, Bradley W. Miller, Ph.D. Post Doctoral Fellow Oak Ridge Institute for Science and Education U. S. Environmental Protection Agency National Risk Management Research Laboratory Land Remediation and Pollution Control Division 5995 Center Hill Avenue, Cincinnati, OH 45224-1702 Office: (513) 487-2889 Miller.BradleyW(a)epa.gov Fax: (513) 569-7879 www.epa.gov www.tinyurl.com/bwmiller The great tragedy of Science—the slaying of beautiful hypothesis by an ugly fact.— Thomas H. Huxley Views or Opinions expressed in this email is solely representative of the sender and does not represents those of the EPA or any other agency.

1 0

Quick first shell (QFS) theory in Artemis
by Bruce Ravel 02 Oct '12

02 Oct '12

Hi all, One of the bugs reported last week involved a project file which made extensive use of the "quick first shell" -- or QFS -- feature of Artemis. The bug involved a problem importing such paths from a saved project file. That bug has been fixed in the 0.9.13 release that I announce a short while ago. This project file that triggered the bug reminded me of an issue that has come up at several recent XAS training courses that I have participated in. In situations where rather little is known about the structure of a material, there is a thought that the QFS tool could provide a model-independent way of generating scattering amplitudes and phase shifts for atoms suspected of being in the material. While the QFS tool is a reasonable thing for atoms in the first coordination shell (hence the name!), this is a dangerous practice for atoms at longer distances. Artemis does not police its misuse in this way beyond simply issuing a warning sugesting that you may be doing something inappropriate. A full discussion of this topic is rather lengthy, so I will refer you to a wiki page that I wrote: http://cars9.uchicago.edu/ifeffit/Demeter/QFS If you have considered using the QFS tool for atoms beyond the first coordination shell, please read that wiki page all the way to the end. Regards, 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