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

Re: continuous scan data
by Webb, Samuel M. 19 Jul '02

19 Jul '02

Matt -- What we've used at DND-CAT is a box-car type averaging to grid the data. Basically, impose a 0.05 A-1 grid and bin all points that lie between a starting and ending point of each point on the grid. Of course, at DND we have data that has been collected at 12.5 kHz, so there are plenty of points to average and get statistical information with... Sam

1 0

Re: Ifeffit digest, Vol 1 #38 - 6 msgs
by Raul Barrea 18 Jul '02

18 Jul '02

Hi Matt, first of all I'd like to say that I have been using Iffefit and Athena for a while and I found both packages very easy to learn and use. I've been following the discussion about how Ifeffit and also athena manage continuous scans and finer grid in energy space. We work in continuous scan mode at BioCAT, so our energy grid cannot be change during the scan as step scans usually do and our energy grid is aprox 1 eV per point, so when we transform this grid to k space we get a not even grid and for most of our point the grid is really smaller than 0.05 A-1. I was very curious about the statistics and how ifeffit and Athena calculate the interpolation. I took one of our scans taken at the Cu K Edge and I remove every other point from it. In order to preserve the grid in the very first region of K I just substitued the high K region from 6 to 13 A-1 with this "new" grid. I found that the results of the original data and the modified data are exactly the same, so the interpolation is not considering the missing points. I've also removed a group of three consecutive points of a goupr of five from the grid (in the same k region) and I found the same results. It will be very usefull if you could include into your package other method that consider every measured point. As you said in your last mail working with finer grid could be a non trivial change but if you could include a better interpolation method will be great. Attached you will fine the three files with the original data and the modified ones (senc-full.xmu; senc-1.xmu and senc-3.xmu). Thanks Raul Raul A. Barrea, PhD Senior Research Associate Illinois Institute of Technology 7900 S Cass Av. BioCAT/APS, Bldg 435B Argonne, IL 60439

2 1

Re: continuous scan data
by Webb, Samuel M. 18 Jul '02

18 Jul '02

Hi all... I've been reading the list about the continuous scan data lately and it looks as if the main issue getting a oversampled grid onto the "standard EXAFS" grid. We've collected a lot of continous scan data DND-CAT at the APS and basically have a routine to bin the data so it resembles a normal step scan (this way you don't loose the statistics and use every point) and then feed it into IFEFFIT. I'm not sure how similar the MR-CAT setup is to the DND collection, but it may be that the conversion process is very similar. To that effect, I have integrated those scipts into an averaging program (now called Sixpack) and analysis suite that uses IFEFFIT. One future development that I hope to add to the program is to be able to read a variety of formats, and allow user definable formats. Until that is complete, it would be simple for me to expand the functionality of what's there to include the MR-CAT continuous scan format... This solution might be able to circumvent the current problems of the splining you have. *********************************************** Street address for courier deliveries: Sam Webb SSRL/SLAC Bldg. 137, MS 69 2575 Sand Hill Rd. Menlo Park, CA 94025 Letters and other mail: Stanford Synchrotron Radiation Laboratory P.O. Box 20450, MS69 Stanford, CA 94309-0210 Phone: (650)-926-3734 FAX: (650)-926-4100 E-mail: samwebb(a)slac.stanford.edu ***********************************************

1 0

Ifeffit 1.0072 released
by Matt Newville 18 Jul '02

18 Jul '02

Hi Everyone, I figured that it had been long enough for version 1.0071, so posted version 1.0072 today. This version has several small feature improvements and bug fixes. There is also a fairly substantial changes to the 'configure ; make ' on Unix, so that the perl and python extensions are no longer built during this process, but have to be built after installation of the library, with the 'normal method' for these languages: cd wrappers/python python setup.py install cd wrappers/perl perl Makefile.PL ; make install This change greatly simplifies the work of the configuration script and is much more reliable. The other major change is that the internals of macro handling were largely rewritten so that nested macros work correctly in all cases (including on windows). Related to that, macros that are run by feffit() and minimize() at each iteration of the fitting loop now run correctly as well. I have a Windows dll ready, but am having difficulty making standalone executables from the ravelware perl scripts. Hopefully that will get worked out soon so that a new Windows installer with the latest athena, artemis, and tkatoms, as well as gifeffit and samxas will be possible. I've also started (but haven't gotten very far on) an annoted collection of ifeffit scripts, intended to be something of a 'how-to' or 'cookbook' for ifeffit commands that will complement the documents and FAQ. Any suggestions or comments on this would be very welcome. Finally, I am really expecting that 1.0072 represents a nearly complete version of Ifeffit 1.0. I believe the XAFS analysis functionality is more-or-less complete at this point. I'm willing to fix bugs, and add small features, but would like to try to leave this version stable and to start working (even if slowly!) on much more significant changes that would eventually become Ifeffit 2. Thanks, --Matt

3 9

Dopants in ATOMS
by Bruce Ravel 18 Jul '02

18 Jul '02

Hi, One of the most common inquiries that finds its way into my mailbox is why the dopants capability in Atoms does not do what the user expects. Typically, the user expects Atoms to write a magical feff.inp file that correctly accounts for the dopants in the material such that FEFF can be run using this magic input file to generate fitting standards or a XANES calculations for the doped material. I get this question so often, that I want to post a response to both the feff and ifeffit mailing lists with an obvious subject line. Then, in the future, I (or even you!) can just point the curious to this posting. ----------- O ----------- First off, this topic is covered in the Atoms document http://leonardo.phys.washington.edu/~ravel/software/exafs/doc/Atoms/Atoms/A… See section 3.4, Dopants. I also discuss this issue in Chapter 10 of the lecture notes for my course on EXAFS Analysis Using FEFF and FEFFIT. http://leonardo.phys.washington.edu/~ravel/course/notes.pdf The discussion in this posting applies to the old versions (2.50 and earlier) of Atoms as well as to the current version. ----------- O ----------- Atoms is, except in extremely contrived situations, not capable of writing a proper feff.inp file for a doped material. This is not a programming shortcoming of Atoms, but a number theoretic limitation imposed by the physical model used by FEFF. In the feff.inp file, there is a big list of atomic coordinates. The reason that people like using Atoms is because, without Atoms, it is a pain in the ass to generate that list. The virtue of Atoms is that it automates that annoying task for a certain class of matter, i.e. crystals. FEFF expects a point in space to be either unoccupied or occupied by a specific atom. A given point may be occupied neither by a fraction of an atoms nor by two different kinds of atoms. Let's use a very simple example -- gold doped into fcc copper. In fcc copper, there are 12 atoms in the first shell. If the level of doping was, say, 25%, then Atoms could reasonably use a random number generator to choose three of the 12 first neighbor sites and replace them with gold atoms. However, what should Atoms do with the second shell, which contains 6 atoms? 25% of 6 is 1.5. Feff does not allow a site to be half occupied by an atomic species, thus Atoms would have to decide either to over-dope or under-dope the second shell. This problem only gets worse if the doping fraction is not a rational (in the number theory sense) fraction, if the material is non-isotropic, or if the materials has multiple sites that the dopant might want to go to. Because Atoms cannot solve this problem correctly except in the most contrived of situations, I decided that Atoms would not attempt to solve it in any situation. If you specify dopants in Atoms' input data, the list in the feff.inp file will be be made as if there are no dopants. This leads to two big questions: 1. Why are dopants allowed in Atoms? 2. How do one deal with a doped sample? The first question is the easy one. Atoms does many things other besides feff.inp generation. Calculations involving tables of absorption coefficients and simulations of powder diffraction and DAFS spectra can use dopant information quite well. The second question is the tricky one and the answer is somewhat different for EXAFS as for XANES. The chapter in the PDF file mentioned at the beginning of this posting discusses one approach to analyzing EXAFS of doped materials. In this posting http://cars9.uchicago.edu/feff/feffusers/msg00022.html Scott Calvin adds his two cents worth. The bottom line for EXAFS analysis is that most dopant problems require running FEFF many times to deal with the wide variety of local environments one finds in a doping problem. One of my papers, A Combined EXAFS and First Principles Theory Study of Pb(1-x)Ge(x)Te, B. Ravel, E. Cockayne, M. Newville, and K.M. Rabe, Phys. Rev. B 60, #21, pp. 14632-14642 (1999). discusses a very thorough approach to one particular case of a doped material. The best approach to simulating a XANES spectrum on a doped material that I am aware of also involves running FEFF many times. One problem a colleague of mine asked me about some time ago was the situation of oxygen vacancies in Au2O3. After some discussion, the solution we came up with was to use Atoms to generate the feff.inp for the pure material. My friend then wrote a little computer program that would read in the feff.inp file, randomly remove oxygen atoms from the list, write the feff.inp file back out with the missing oxygens, and run FEFF. He would do this repeatedly, each time replacing a different set of randomly selected atoms and each time saving the result. This set of computed spectra was then averaged. New calculations were made and added to the running average until the result stopped changing. If I remember, it took about 10 calculations to converge. This random substitution approach would work just as well for dopants as for vacancies. I hope that is helpful. B -- Bruce Ravel ----------------------------------- ravel(a)phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b 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/

1 0

artemis and athena updates
by Bruce Ravel 17 Jul '02

17 Jul '02

Hi folks, So, today I tried to actually analyze some data that is long overdue for some attention. I didn't get much analysis done, but I did find and fix lots of bugs in Artemis and Athena. Artemis: ** fixed a bug which precluded using third or fourth cumulants in fits (that was rather serious!) ** clicking buttons in the plot options section does redisplay ** data gets plotted in R when reading data files, project files, or feffit.inp files ** fixed a bug which made every item in the "select paths for fitting" menu fail ** title lines now get correctly restored from project files ** a few internal changes that affect how fits get run and results get displayed Athena: ** now using the sort argument to read_data, as was discussed in some mail earlier today ** disable "save as" menu items for spaces that do not make sense for the current record ** fixed a bug in how markers get displayed in energy plots ** fixed a few other minor bugs, see CHANGES file for details New source tarballs are now on my website. Regards, B P.S. I have been working pretty hard lately on the codes and making lots of releases. Indeed, this is my fourth tarball announcement during July! That's the open-source philosophy -- "release early and often". I don't really expect everyone to update their system everytime I announce a new tarball. Therefore, I am trying to make it clear what the major changes are so you can decide if you need to upgrade. Athena and Atoms are pretty stable these days -- you probably only need to upgrade if a change addresses a bug that you have noticed yourself. Artemis, on the other hand, is changing pretty dramatically. Each release lately has addressed some serious usability issues. It may even be useful soon ;-) -- Bruce Ravel ----------------------------------- ravel(a)phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b 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/

1 0

new source tarball for Artemis
by Bruce Ravel 16 Jul '02

16 Jul '02

Hi folks, I posted a new source tarball for Artemis on my website. Lots of improvements this time, including: ** a check to see that all guess parameters are used and that all math expressions use parameters that have been defined ** rearrangement and improvement (I hope!) of the page for defining guess, def, and set parameters ** fixed more problems that cropped up after deleting individual feff paths or entire feff calculations. I know I said I had fixed this in the last release, but this time I think I mean it!! ** many more features of Artemis can operate on the group of selected paths, including deletion of paths, exporting path parameter values, and editing path parameter values ** fixed a problem where, in certain situations, the array containing the background function refined during a fit was overwritten by another array. This resulted in messed up plots after doing fits with background refinements. ** and a bunch of minor things -- see the CHANGES file for details A windows update will follow soon. Regards, B -- Bruce Ravel ----------------------------------- ravel(a)phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b 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/

1 0

new releases of Atoms, Athena, and Artemis
by Bruce Ravel 11 Jul '02

11 Jul '02

Hi all, I just wanted to follow up Matt's announcement of the Windows preview release yesterday. It includes versions of my programs that have been updated in the last two weeks. For those of you who are linux, unix, or OSX users, source code tarballs of the latest versions can be found on my web site. For Atoms the big changes are mostly in the parts of the code that compute absorption cross sections from the McMaster, Elam, or other tables. Several bugs were fixed, including some severe problems in the McMaster tables and a bug which resulted in negative (i.e. unphysical) normalization corrections in some situations. For Athena the changes are fairly numerous and include bug fixes, changes to the column selection dialog, changes to the behavior of the groups list, and a few other things. For Artemis, I have squashed a lot of bugs which lead to strange behavior or crashes. Many of the problems had to do with deletion of feff paths. That is now fixed and should work as expected. As always, poke at them and let me know what needs fixing. Special thanks this time to Simon Bare and Paul Fons for very helpful bug reports. B -- Bruce Ravel ----------------------------------- ravel(a)phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b 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/

1 0

Test Windows Installer for Ifeffit++
by Matt Newville 09 Jul '02

09 Jul '02

Hi Everyone, There's a new version of the ifeffit windows installer available at http://cars.uchicago.edu/ifeffit/src/iffsetup_jul09.exe This installer uses ifeffit 1.0072 and includes the latest versions of atoms, athena, and gifeffit, and now includes artemis, sixpack, and a few other applications. The main point of this release is to check the installation process and the running of all the newly available programs. I'm expecting that we'll need to make some minor changes to some of the applications, but I'd like to get a release that can be stable for several months, so would greatly appreciate as much testing of these versions as possible. So, all you Windows users out there, here's your chance to help out! Please try this installer out, and trying running all the programs. If any of them don't run or crash immediately, please let us know. The installer is now 20Mb, and expands to a directory that uses about 50Mb. If this is a problem, please let us know: we could probably split the distribution into separate installers for different programs. Thanks, --Matt

1 0

The so-called ravelware packages
by Bruce Ravel 05 Jul '02

05 Jul '02

Hey, Today Matt asked me why I don't make one big tarball with Atoms, Athen, and Artemis all in it. Apparently a few people have complained to him about problems upgrading them one at a time. I think that having one big tarball is a great idea and, in fact, I have been looking forward to the day when all three would be basically stable and ready for real work. Atoms and Athena are there. Artemis should be soon. I'll probably keep with the separate tarballs thing for my own convenience for a short while longer, but I suspect that in the next couple of months I'll start doing one huge tarball. If anyone has a compelling reason for me *not* to do so, speak up! B -- Bruce Ravel ----------------------------------- ravel(a)phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b 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/

1 0