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

Warning: ifeffit users on Mac OS X
by Jeff Terry 24 Aug '02

24 Aug '02

Hello, If you are dependent upon ifeffit under OS X, DO NOT install the 10.2 upgrade. This upgrade breaks the readline library which is needed by ifeffit. A quick web search showed this to be a known problem with no current solution. Readline does not currently compile under 10.2. I tried a cursory effort compilation which resulted in many missing symbols. Jeff

1 0

Warning:ifeffit on OS X
by jterry94＠mac.com 24 Aug '02

24 Aug '02

Do not install OS X 10.2 if you rely on ifeffit under OS X. The readline libraries break and ifeffit cannot be used. A quick web search revealed that others have seen the problem and a quick attempt to recompile readline by myself has failed: missing symbols. Jeff

1 0

ifeffit 1.0073 released
by Matt Newville 19 Aug '02

19 Aug '02

Hi Everyone, I've posted Ifeffit 1.0073, both source code and Windows installer, on the ifeffit download page. Following the earlier discussion of interpolation schemes for continuous scan data, this source code has added 'interp=' options ('interp=line', 'interp=quad', 'interp=cubic') to the spline() and bkg_cl() commands. There are no other major changes to the base library, but a few minor improvements and bug fixes in the source. The Windows installer includes the latest (I believe!!) of athena, artemis, sixpack, and even gifeffit. Also, on Windows, the GrWin plot window now raises to the top at every plot(), cursor(), and zoom() command. Enjoy, --Matt

1 0

symmetry in Atoms
by Bruce Ravel 19 Aug '02

19 Aug '02

Here is an interesting question that was waiting in my mailbox this morning. I thought folks on the ifeffit list might also find it interesting and, in any case, it seems useful to have the question and the answer in the ifeffit list's archive. B The attached EXCEL file is the structure data for Fe17Y2 referred from Pearson's Handbook. Actually I get FEFF.inp file by Atoms using the input data as attached list. I wondered, howevere, how Atoms recognize site symmetry thorough the Atoms.inp data. My question is that the input data for each symmetric site should fulfill the site symmetry like as following list. In case of Fe17Y2 (No. 194), when I input (0 0 1/4) then Atoms will automatically recognizes this is 2b site. But when I input the number (0.1672 0.3344 0.9874) for 12k-site, how Atoms recognizes this is 12k site. Or if input numerical numbers do not fulfill the symmetry condition, then how Atoms deal with it. Thank you for your attention. space group number : 194 setting : 1 Hermann-Mauguin : P 6_3/m 2/m 2/c Laue group : 6/mmm point group : 6/m mm positions 24 l x,y,z -y,x-y,z -x+y,-x,z -x,-y,z+1/2 y,-x+y,z+1/2 x-y,x,z+1/2 y,x,-z x-y,-y,-z -x,-x+y,-z -y,-x,-z+1/2 -x+y,y,-z+1/2 x,x-y,-z+1/2 -x,-y,-z y,-x+y,-z x-y,x,-z x,y,-z+1/2 -y,x-y,-z+1/2 -x+y,-x,-z+1/2 -y,-x,z -x+y,y,z x,x-y,z y,x,z+1/2 x-y,-y,z+1/2 -x,-x+y,z+1/2 12 k x,2x,z -2x,-x,z x,-x,z -x,-2x,z+1/2 2x,x,z+1/2 -x,x,z+1/2 2x,x,-z -x,-2x,-z -x,x,-z -2x,-x,-z+1/2 x,2x,-z+1/2 x,-x,-z+1/2 12 j x,y,1/4 -y,x-y,1/4 -x+y,-x,1/4 -x,-y,3/4 y,-x+y,3/4 x-y,x,3/4 y,x,3/4 x-y,-y,3/4 -x,-x+y,3/4 -y,-x,1/4 -x+y,y,1/4 x,x-y,1/4 12 i x,0,0 0,x,0 -x,-x,0 -x,0,1/2 0,-x,1/2 x,x,1/2 -x,0,0 0,-x,0 x,x,0 x,0,1/2 0,x,1/2 -x,-x,1/2 6 h x,2x,1/4 -2x,-x,1/4 x,-x,1/4 -x,-2x,3/4 2x,x,3/4 -x,x,3/4 6 g 1/2,0,0 0,1/2,0 1/2,1/2,0 1/2,0,1/2 0,1/2,1/2 1/2,1/2,1/2 4 f 1/3,2/3,z 2/3,1/3,z+1/2 2/3,1/3,-z 1/3,2/3,-z+1/2 4 e 0,0,z 0,0,z+1/2 0,0,-z 0,0,-z+1/2 2 d 1/3,2/3,3/4 2/3,1/3,1/4 2 c 1/3,2/3,1/4 2/3,1/3,3/4 2 b 0,0,1/4 0,0,3/4 2 a 0,0,0 0,0,1/2 The attachment contained this: Fe17Y2 "structure type" "Pearson Smmbol" "space group" No Fe17Ho2 hP44 P6_3/mmc 194 Wyckoff x y z occupncy Y1 2b 0 0 0.25 0.41 Y2 2c 0.3333 0.6666 0.25 0.35 Y3 2d 0.3333 0.6666 0.75 1 Fe1 4e 0 0 0.1103 0.28 Fe2 4f 0.3333 0.6666 0.1049 0.71 Fe3 6g 0.5 0 0 1 Fe4 12j 0.3341 0.964 0.25 1 Fe5 12k 0.1672 0.3344 0.9871 1 And my response: Well, you made it very easy for me to answer your question by including the symmetry table for your space group in your email. The answer is that Atoms reads a data base of the space group symmetries. For your example, #194, the data base entry contains this information: x,y,z -y,x-y,z -x+y,-x,z -x,-y,z+1/2 y,-x+y,z+1/2 x-y,x,z+1/2 y,x,-z x-y,-y,-z -x,-x+y,-z -y,-x,-z+1/2 -x+y,y,-z+1/2 x,x-y,-z+1/2 -x,-y,-z y,-x+y,-z x-y,x,-z x,y,-z+1/2 -y,x-y,-z+1/2 -x+y,-x,-z+1/2 -y,-x,z -x+y,y,z x,x-y,z y,x,z+1/2 x-y,-y,z+1/2 -x,-x+y,z+1/2 which you will recognize as Wyckoff's position "l". Atoms doesn't exactly distinguish between Wyckoff's position l and position b. Instead it assumes that everything is position l and discards repeated positions. To understand this, apply the symmetry operations in the list above to the position (0,0,1/4). You will notice that 12 of them generate the position (0,0,1/4) and 12 of them generate (0,0,3/4). Atoms notices that and discards 11 of each. So, you see, position b is not actually different from position l, it's just degenerate due to symmetry. Atoms will notice these degeneracies a posteriori and does not need to know about the a priori. So, where did Wyckoff get his notation scheme from? Well, the Wyckoff positions are simply ordered in terms of decreasing degeneracy. Position a is the most degenerate and the highest lettered position is the non-degenerate one. This is not actually a useful notation scheme because there is no consistency between space groups. That is, position "c", for example, in group 194 has no relationship to position "c" in any other space group. The last thing worth mentioning is that Atoms works with 5 significant digits. If you use, as you suggest, (0.1672 0.3344 0.9874) then Atoms will find the correct amount of degeneracy. However, how you write (1/3, 2/3, z) is very important. Atoms 3.0 is able to read the string "1/3" as a coordinate. However if you choose to write coordinates in decimal notation, you must be careful. (0.33333, 0.66667, z) is fine and will generate 4 positions. (0.33, 0.67, z) will have problems related to numerical precision. Hope that's clear, Bruce -- 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

Atoms 3.0beta7
by Bruce Ravel 15 Aug '02

15 Aug '02

Hi folks, I released a new version of Atoms today which includes one small (but possibly important) change from the previous version. I learned that the database entry for a specific space group (I -4 3 d, #220) was in error. I fixed this and made a new release. There is a new tarball and Windows executable on my web site. If you are a windows user, you will also need to install the new version of the space_group.db file, as per the instructions on the downloads page. I also updated WebAtoms on Matt's server. This error has ABSOLUTELY NO IMPACT on any other space group. Indeed, without an atoms input file using the affected space group, you would never notice the problem. This underscores an interesting aspect of crystallography. While group theory tells us that there are 230 possible space group, nature seems to prefer using only a small subset of them. Indeed, in all the years since I started working on Atoms, I have not seen an example of a crystal in this space group until this week. The collection of input files that I distribute with Atoms for the purpose of testing the code includes examples of less than 80 space groups. Anyway, here is the input file that lead me to the error in Atoms' space group data base: title = Cu3As Domeykite title = Iglesias, J. E., and Nowacki, W., title = Zeitschrift fur kristallographie, kristallgeometrie, title = kristallphysik, kristallchemie, v. 145, pp. 334-345 (1977). space = I -4 3 d a = 9.6190 core = Cu rmax = 8.0 atoms ! elem x y z Cu -0.02930 0.12020 0.18760 As -0.02980 -0.02980 -0.02980 One might notice that the old Fortran version of Atoms handles this input file correctly. The irony of that is not lost on me, particularly in light of my frequent and loud trumpeting of the advantages of the new version over the old version. Thanks to Elspeth Barnes for bringing this problem to my attention. 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

athena 2002.08.14
by Bruce Ravel 14 Aug '02

14 Aug '02

Hi, I put a new tarball and Windows build for Athena on my website this afternoon. There are only a few changes since last week, but they are interesting enough to merit a new release. 1. I fixed a problem in the display of the group list. When deleting groups, slightly more vertical space was removed than had been allocated when the group was listed. This lead to a misalignment that was particularly apparent when deleting many groups. 2. I now do the thing where the cursor changes to a stop watch (an hourglass on Windows) whenever Athena is doing anything time consuming. That keeps you from clicking buttons as a bad time and also gives you a visual cue when lengthy procedures finish. 3. I put in more careful checks of memory usage. I had a bug report that was traced back to a large quantity of data overflowing Ifeffit's static memory space. I now check memory usage more frequently and issue a warning message when the amount of memory is running short. The scheme is not foolproof. It is still possible to overflow the memory before triggering a warning, but Athena should catch many situations in which this might happen. 4. It is now possible to create a "background group". That is a data group which is listed in the groups list and which contains as its data the background function computed from another data group. This is useful for at least three things, including directly comparing different background functions, comparing a background function to a background computed by FEFF and read from the 5th column of xmu.dat, and investigating low-R phenomena such as multi-electron effects or the so-called atomic xafs. 5. Project files now identify the version of perl, the version of ifeffit, and the operating system of the computer along with the version of Athena used to create the file. This is information I need when I am sent a project file as part of a bug report. There is no problem with backwards compatibility -- project files without this information will be read without problem. And project files continue to be transferable between platforms. The tarball and the Windows exe are in the standard places. Special thanks to Raul Barrea for a very useful bug report which lead to most of this week's new features. 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

athena 2002.08.08 and artemis 2002.08.08 released
by Bruce Ravel 09 Aug '02

09 Aug '02

Howdy folks, This afternoon I put new source tarballs of Athena and Artemis on my website. I also build Windows executables of both programs for dropping on top of a current ifeffit installation (with the Splashscreen commented out!). These can be found in the standard places. These are mostly bug fix releases, although each program got one major new feature. For Athena the highlights are: 1. the column selection dialog now makes a stab at figuring out if you have transmission or fluorescence data. How it does this is configurable (so that it'll work well on your data files) but currently undocumented. Ask on this list if you want to know. 2. fixed a bug in the auto-align feature wherein the e0 shift of the alignment standard was ignored 3. fixed a horrid bug in the merge code where I added the e0 shift to the k-array when merging in k. (yikes!) 4. write a message to the Echo area if the plot multiplier is set to 0, which is usually not a good choice 5. added some complicated logic to avoid plotting groups if any relevant range is backwards. For example, if fft_kmin is greater than fft_kmax for a group, that group will not be plotted in R or q space and a (hopefully) helpful message will be printed to the echo area. 6. a few other minor problems were fixed and some usability issues on Windows were addressed (mostly having to do with raising small windows to the top of the screen) For Artemis the highlights are: 1. If you right-click on a word in one of the entry boxes for path parameter math expressions on a Path page, a menu will pop up which allows you to easily set that word as a parameter. It's very useful, but a little hard to explain. Here are some screen shots that might help: http://leonardo.phys.washington.edu/~ravel/software/exafs/images/artemis/be… http://leonardo.phys.washington.edu/~ravel/software/exafs/images/artemis/af… In the first picture, I right-clicked on the word "amp". After selecting the "guess" option from the menu, the view is switched to the GDS page and focus is given to highlighted box so you can start typing. This feature works sensibly for parameters which already exist and for those that have not yet been defined. 2. fixed a problem which prevented saving path data in any space 3. fixed a problem reading a project file with multiple feff calculations 4. a few other fixes to functionality and usability Extra special thanks to Mark Jensen, Paul Fons, and Kumi Pandya for useful bug reports and to Shelly Kelly for suggesting the right-click thing in Artemis. Enjoy and, as always, let me know what needs fixin' 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

Re: ifeffit and perl 5.8.0
by Carlo U. Segre 01 Aug '02

01 Aug '02

I am still using Atoms beta5 myself because I have not been successful in getting beta6 to compile. I just hadn't gotten around to figuring out if it was me or a real problem. Carlo On Thu, 1 Aug 2002, Dr. Paul Fons wrote: > > > I have now gotten perl 5.8.0 to work with both athena and artemis. As > Carlo said in an earlier message, the binaries of 5.6 and 5.8 are not > compatible and it necessitates rebuilding compiled packages. There is > an OS X problem as well in that the make install command for perl 5.8 > doesn't seem to overwrite all of the files so I manually deleted the old > installation and did a make install in the perl 5.8 directory. The > weird thing is that only tkatoms (B6) doesn't recompile. I can't even > do a perl Makefile.PL without getting an error. Any ideas? > > > Here is a clip: > > perl -v > This is perl, v5.8.0 built for darwin > ... > > > [etld1220:~/Ports/Atoms-3.0beta6] paulfons% perl Makefile.PL > dyld: perl Undefined symbols: > _Perl_safefree > _Perl_safemalloc > _Perl_saferealloc > _Perl_sv_2pv > _perl_call_sv > _perl_eval_sv > _perl_get_sv > > -- Carlo U. Segre -- Professor of Physics Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre(a)iit.edu http://www.iit.edu/~segre

1 0

Re: Ifeffit digest, Vol 1 #42 - 1 msg
by Raul Barrea 01 Aug '02

01 Aug '02

Hi Bruce, I've downloaded the exec file you've posted in your web site. Atoms and the periodic table work fine but Athena and Artemis don't work. Maybe there is something missing. Are the dll's the same for the old and new versions of the exec files? Thanks Raul Barrea BioCAT/APS ----- Original Message ----- From: <ifeffit-request(a)millenia.cars.aps.anl.gov> To: <ifeffit(a)millenia.cars.aps.anl.gov> Sent: Tuesday, July 23, 2002 12:01 PM Subject: Ifeffit digest, Vol 1 #42 - 1 msg > 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-admin(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. serious athena bug fix (Bruce Ravel) > > --__--__-- > > Message: 1 > Date: Mon, 22 Jul 2002 18:15:24 -0400 > To: ifeffit mailing list <ifeffit(a)millenia.cars.aps.anl.gov> > Reply-To: ravel(a)phys.washington.edu > From: Bruce Ravel <ravel(a)phys.washington.edu> > Subject: [Ifeffit] serious athena bug fix > > > Hi folks, > > Today Shelly Kelly pointed out a serious bug in the code that merges > spectra. Spectra merged as mu(E) or norm(E) have not ever been > calculated correctly. There were several problems -- the worst was > that the e0 shifts for all groups involved in the merge were ignored. > This resulted in numerous problems with the merged spectra. > > I think I have fixed the problem -- at least the sample data that > Shelly gave me now gets merged correctly. There is a new source > tarball on my web site. > > I also added a couple of trivial features to both athena and artemis. > The first is a splash-screen, i.e. something to look at in those > endless seconds between double clicking on the icon and having the > program spring to life on the screen. I also added several keyboard > shortcuts for common tasks in both programs. You can see what these > are by examining the menus in the menubar. > > > I also added something new to my web site. Athena and Artemis change > much faster than Ifeffit these days. The bad part of this is that > Windows users don't get to take advantage of my updates as often as > unix and OSX users. So today I added a section to the downloads page > with links to the executables of my four programs. I doubt I will > update the executables as often as I update the source tarballs. But > when I do, I'll post the executables on the downloads page. > > The idea of these individual executables is that you replace the > executable in the C:\Program Files\Ifeffit\ folder with the new one. > These executables now found on my downloads WILL NOT RUN CORRECTLY > outside the context of a properly installed ifeffit package. But if > you have installed Ifeffit using the installer from Matt's web page, > you will be able to drop my new executables in place. > > 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/ > > > --__--__-- > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > > End of Ifeffit Digest

3 2

Perl 5.8 and ifeffit
by Dr. Paul Fons 31 Jul '02

31 Jul '02

I have now gotten perl 5.8.0 to work with both athena and artemis. As Carlo said in an earlier message, the binaries of 5.6 and 5.8 are not compatible and it necessitates rebuilding compiled packages. There is an OS X problem as well in that the make install command for perl 5.8 doesn't seem to overwrite all of the files so I manually deleted the old installation and did a make install in the perl 5.8 directory. The weird thing is that only tkatoms (B6) doesn't recompile. I can't even do a perl Makefile.PL without getting an error. Any ideas? Here is a clip: perl -v This is perl, v5.8.0 built for darwin .... [etld1220:~/Ports/Atoms-3.0beta6] paulfons% perl Makefile.PL dyld: perl Undefined symbols: _Perl_safefree _Perl_safemalloc _Perl_saferealloc _Perl_sv_2pv _perl_call_sv _perl_eval_sv _perl_get_sv Dr. Paul Fons Photonics Research Institute National Institute for Advanced Industrial Science and Technology Ministry of Economics and Trade Umezono 1-1-1 Tsukuba, Japan 305-8568 tel. 81-298-61-5636 fax. 81-298-61-5615 paul-fons(a)aist.go.jp Lines below are in Japanese 独立行政法人産業技術総合研究所光技術部門〒305-8568 茨城県つくば市梅園1-1-1 産総研つくば中央第2 E-mail: paul-fons(a)aist.go.jp, Tel. 0298-61-5636, Fax. 0298-61-5615

1 0

Carlo's message and perl 5.8.0
by Bruce Ravel 31 Jul '02

31 Jul '02

Hey, I just thought I would drop a short note to the list explaining in fewer words what Carlo said. The bottom line is that 5.8 and 5.6 are not binary compatible. This is an annoyance that affects many things, including the ifeffit interface. The solution is to go to the place where you unpacked ifeffit and cd to the wrappers/perl/ directory. Rebuild the ifeffit interface by doing make clean perl Makefile.PL make make install I don't think you'll actually need to reinstall athena, but it couldn't hurt. This is not a OSX-only, or debian-only problem. We will all have this annoyance when we get around to updating to perl 5.8 That doesn't make me happy, but I'll deal. Starting to distribute a big tarball with the ifeffit interface bundled with all my codes will actually go along way towards solving that problem. And, if you are not updating to perl 5.8 (or don't even grok what this discussion is about), then you will probably not be affected by this issue. Thanks Carlo! B Bruce Ravel e-mail: ravel(a)phys.washington.edu URL: http://feff.phys.washington.edu/~ravel/

1 0

Perl 5.8.0 packages (fwd)
by Carlo U. Segre 31 Jul '02

31 Jul '02

In reference to the recent mail about Perl 5.8.0. This is specific to the Linux Distribution (Debian) that I use but it explains why version 5.8.0 is not drop in compatible with athena and artemis. Carlo -- Carlo U. Segre -- Professor of Physics Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre(a)iit.edu http://www.iit.edu/~segre ---------- Forwarded message ---------- Date: Wed, 31 Jul 2002 23:18:29 +1000 From: Brendan O'Dea <bod(a)debian.org> To: "debian-devel-announce(a)lists.debian.org" <debian-devel-announce(a)lists.debian.org> Cc: Debian Perl List <debian-perl(a)lists.debian.org> Subject: Perl 5.8.0 packages Resent-Date: Wed, 31 Jul 2002 08:20:14 -0500 Resent-From: debian-devel-announce(a)lists.debian.org Perl 5.8.0 packages are currently being tested in a staging area: deb http://auric.debian.org/~bod perl/$(ARCH)/ deb-src http://auric.debian.org/~bod perl/ the principal reason for a staging area is that these packages are not binary compatible with the previous perl packages, which means that all binary (XS) modules and programs embedding a perl interpreter will need to be rebuilt. The complete list of packages which will require a rebuild may be obtained by running: apt-cache showpkg perlapi-5.6.0 perlapi-5.6.1 libperl5.6 In addition, since the perl 5.8.0 packages break binary compatibility I've chosen to enable ithreads which may affect some of the packages listed above--notably if packages embedding an interpreter declare their own xs_init subroutine rather than generating one with ExtUtils::Embed::xsinit may need to add a pTHR argument to that function.

1 0

(no subject)
by Bruce Ravel 29 Jul '02

29 Jul '02

Paul said: PF> Just for fun, I tried installing the new perl 5.8.0 release on PF> Mac OS 10.1.5. The perl installation went fine (all the tests PF> passed that should), however, when I tried to reinstall ifeffit, PF> problems ensued. The installation attempt (the very tip) is PF> pasted below. Is this a sign of problems to come? I don't know PF> perl well enough to know where these modules came from. For the PF> moment my resolution is to install perl 5.6.1 (a slight upgrade PF> from the default 5.6.0 included with the OS) I haven't tried perl 5.8.0 myself yet. I presume that there will not be any issue with my code, but obviously I haven't tested it. My best suggestion is to install the ifeffit wrapper by itself without athena. (If you are using an older ifeffit distribution which has an athena subdirectory under wrapper/perl/, delete the athena subdirectory before building the wrapper.). Then install athena afterwards. My next, and more annoying, suggestion, is to clean up any traces of ifeffit's perl inteface (i.e. any instances of the files Ifeffit.pm, Ifeffit.bs, and Ifeffit.so) then try again. All of this points to something that I brought up on the list a while ago and which Matt has been advocating for. It would probably be best to make on big package with the the Ifeffit/perl inteface and my programs all bundled together and distributed separately from Ifeffit. I'll look into that next month. 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
by Bruce Ravel 28 Jul '02

28 Jul '02

Hi Folks, I belive that I have solved the problems that I discussed earlier today for athena and artemis on both windows and unix. I have uploaded new tarballs and windows executables to the "downloads" page. Mark Jensen and Raul Barrea have confirmed that the windows executables posted today work as expected when you drop them into an existing Ifeffit distribution. Thanks guys! Sher Alam informed me of the problem with the missing module in the tarballs. I believe that I have solved that problem, but I would be grateful if you would let me know how it works for you, Sher. I also fixed yet another problem with merging in energy space which was discovered by Shelly Kelly. I believe that I have it working correctly now, but I am sure someone will let me know if that's not the case! This bug is fixed in today's tarballs AND Windows executables. Thanks to Mark, Raul, Sher, and Shelly. I am, as always, quite grateful. 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/

2 1

continuous scan data
by Matt Newville 28 Jul '02

28 Jul '02

Hi Everyone, I made some small, probably incomplete, progress on dealing with the problem of continuous scan (or QEXAFS) XAFS data for which the XAFS data is sampled on a fine energy grid -- 1eV was used for the data Raul posted. As mentioned earlier, Ifeffit currently uses a fixed k-grid of 0.05Ang^-1 for chi(k). At k = 10Ang^-1, this corresponds to energy steps of nearly 4eV. Any scheme to use "all the data" to map to chi(k=10) may be tricky. The basic approaches are 1) better interpolation algorithm. 2) change the k-space grid size. 3) doing some sort of averaging of the data around a particular k value. At this point I've tried the first 2 of these. More details are posted at http://cars9.uchicago.edu/ifeffit/qexafs/ including data files and some plots figures. This is all with 'experimental' versions of ifeffit. First, I made the interpolation scheme used for the translation of chi(E) to chi(k) in the spline command have a few options: 'linear' using two surroundings data points 'quadratic' or parabolic using three data points 'cubic spline' put a cubic spline through all the data points Linear interpolation is not very satisfying. The results from 'quadratic' and 'cubic spline' are very similar. The next thing I did was to change the k-grid spacing from 0.050 to 0.025 and to 0.010 Ang^-1, and repeated the use all 3 interpolation schemes. Using 0.050 is noticeably different from 0.025, while 0.025 and 0.010 seem pretty similar to me. This was all done by changing the kgrid at compile time, which will be possible in 1.0073. I also played around with trying to make the kgrid and size of the FFT array variables that can be set at run-time. This seems highly desirable for cases like this. Surprisingly to me, it also seems possible. I have a *highly* experimental version that allow kgrid to be set at run time. In favorable conditions, it even works correctly. There are still some severe bugs with this version that I do not fully understand, and I doubt I'll have much time to work on it soon. But if anyone is very eager to try it, I'd be willing to send it. I have not yet tried implementing any 'averaging of adjacent points' such based on a rolling boxcar or a convolution with a Lorenztian. I could be persuaded to try such things, but at this point I'm not sure what the right thing is. Finally, coming back to the interpolation of the continuous scan data, the data Raul sent has some systematic effects going on that might complicate these comparisons. The effects can be seen from the un-interpolated chi(k) data: http://cars9.uchicago.edu/ifeffit/qexafs/orig_data_zoom.png and the attempts to interpolate this data: http://cars9.uchicago.edu/ifeffit/qexafs/kgrid_zoom.png It looks like there are systematic trends due to insufficient precision (only 4 digits in the mu(E) data). I don't know enough about the electronics used to know if this is intrinsic to the measurements or not. Also, does anyone know how accurate the energies are with this kind of data? Thanks, --Matt

1 0

Re: GIFeffit bugs
by Matt Newville 28 Jul '02

28 Jul '02

Hi Raul, On Fri, 26 Jul 2002, Raul Barrea wrote: > I was working with Gifeffit for windows and I save a session > file as ifeffit.sav but I couldn't open it again. Could you > please check it to see what can be wrong? Yes, GIFEFFIT is not handling the opening of files in directories with spaces in their name. It appears that save files are written correctly and can be read from a directory without a space in the name, but not if there is a space in the name. Should be easy to fix. > I found that log(my_logfile.log) is not working properly in > the windows version of GIfeffit. The program literally > crashes. A visual fortran run time error window appears. This > is not a serious bug but I think you must know it. I think this is related to all the other problems that result in a Visual Fortran Error of the form: forttl: severe (38): error during write, unit -1, file CONOUT$ .... which are come from GUIs that have no DOS console associated with them for simple print statements to be sent. These messages should not be necessary, but making sure that they never happen is harder. A solution should be fairly easy. I hope to post a version with fixes for both of these problems later today or tomorrow. > By the way, have you had any time to find a solution to the > interpolation routine to include all the statistics available > in the experimental data? I've made some progress, but not a complete solution. I'll send a separate post on this later today. --Matt

1 0

Re: [Ifeffit] athena / artemis
by Bruce Ravel 25 Jul '02

25 Jul '02

Hi folks, On Monday I was rushing to get updated versions of Athena and Artemis finished so I could go on a two day trip to NSLS on Tuesday and Wednesday. In my rush, I posted broken versions of Athena and Artemis on my web site. Upon my return, I found my mailbox overflowing with reports of problems. For the Windows users: I belive that Matt correctly identified the problem. I, of course, installed the logos for the splashscreens on *my* computer, but forgot that no one else would have them installed on theirs. That's none too bright! Matt sent me personal email while I was gone stating that he is almost ready to release 1.0073. So here is what I propose. I'll build new executables that do not use the splashscreens and wait for 1.0073 to release that feature. In the future, I'll try very hard to remember to post any new files that need to go into the distribution. Thanks to Mark Jensen, Raul Barrea, and Matt for downloading the executables and reporting back with their problems. For the Unix users: The splashscreens appear to be a problem for unix types as well. The code which handles the splashscreen makes use of a perl module that I had thought was part of the standard distribution but which, in fact, is not. The solution is simple. I'll include the missing module in the source tarballs for athena and artemis and post the new tarballs later today. Thanks to Sher Alam for pointing out this problem. I'll send mail out to the list later today when the new executables and tarballs are in place. Once again, thanks to all of you for taking the time to provide feedback. Your help is very much appreciated. 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

Re: FT padding
by Matt Newville 23 Jul '02

23 Jul '02

Dear Marcus, Recently, Marcus Karolewski wrote: > Dear Matt, > > I have been looking thro' your (highly informative) PhD thesis today in the > hope of finding some discussion about the zero padding used in FT > operations on XAFS data, but there doesn't seem to be any direct reference > to the reasoning behind it, although I gather you padded your data up to 25 > A-1. > > I realise that FT padding makes the data look nice in R-space, but I'd like > to ask whether you know of any other benefit to be gained from it. To my > way of thinking, there seems to be a definite drawback to padding insofar > as one ends up with data that consist mostly of interpolated points in R > space. This would seem to make a mockery of the fitting criteria which > strictly should be based on the actual number of points justified by the > range of the expl data. I would be very interested to hear your comments if > you can find the time. Excellent question! I hope it's OK if I CC this to the ifeffit mailing list, as it's relevant to a current discussion there on interpolating QEXAFS data, and because others might be interested or have opinions on this as well. Short answer: Yes, zero-padding is mostly to make the data look nice in R-space. A mockery of the fitting criteria?? I wouldn't go that far! Just for reference, the important values for the FTs are: kgrid: the k-grid spacing needs to get 'all the features'. N_fft: the FFT should use a number of points = a power of 2, even if zero-padding is used. rmax: the largest frequency that can be seen. rgrid: the resulting grid spacing in R should be small enough to avoid missing real features in R-space. Ifeffit uses kgrid=0.05Ang^-1 and zero-pads chi(k) to have N_fft=2048. The outputs from feffit also use these values. rmax and kgrid are simply related: rmax = pi /(2* kgrid) ~= 31.4 Ang for kgrid=0.05 The spectra above Rmax are a mirror image of the lower-R portion of the spectra: chi(R) = chi(2*Rmax-R) for R > Rmax 31.4Ang is much further than the XAFS really extends, but we can use the high portion to estimate the noise in the signal (feffit does this). So, we probably wouldn't want to go to kgrid=0.10 & rmax=16Ang. In fact, we might be tempted to use a smaller kgrid. The spacing of the R-space data, rgrid, is given as rgrid = pi / (kgrid * N_fft) For N_fft=2048 and kgrid=0.05Ang^-1, rgrid~=0.03Ang. If we had N_fft = 512, we'd have kmax = 0.05 * 512 = 25.6Ang-1 which is probably reasonable -- I've seen a few data sets past 25Ang^-1, but these are rare. We'd also have rgrid = pi / (0.05 * 512 ) = 0.122 Ang This has the advantages of giving data points in R that is closer to the 'real spacing' of "pairs of independent data points" in R-space: Delta R ~= pi / (K-range). The emphasis here should be on the 'approximate' sign. It is tempting to interpret this formula as "my independent data points are exactly 0.XXX Ang apart", but this is a serious overstatement. A better interpretation is that distances separated by less than (2pi/K-range) will be very difficult to distinguish. Using a coarser R spacing does make the fits faster. In fact, feffit (the program) does NOT use N_fft = 2048 when doing the fits -- it uses either 256, 512, 1024, or 2048 depending on the data k-range. This does indeed speed up the fits (for all output arrays, N_fft=2048 is used to make the plots prettier). Long ago (when computers ran on diesel), N_fft=128 was also allowed, but this was not reliable because there was a good chance of getting stuck in a 'false minima' with data that sparsely spaced in R. I've seen such false minima happen a few times, and took out the option of using N_fft = 128. Because it's painful to constantly switch N_fft, ifeffit currently uses kgrid=0.05 and N_fft = 2048 throughout. I have started working toward having these be changeable at will inside the program, but this still causes a few problems at the moment. Anyway, I wouldn't say that using zero padding and a large N_fft is really cheating much. It's really just oversampling the data. An FT is linear, so zero-padding does not change your data (much), but just convolves the 'independent data points' with Gaussian functions. Finally, zero-padding does change your data some because it means that you are asserting that chi(k)=0 for k>kmax. A better approach would be to pad with random noise at a level consistent with your data. This could be done, I suppose, but has not been done yet. Hope that helps, --Matt

1 0

serious athena bug fix
by Bruce Ravel 22 Jul '02

22 Jul '02

Hi folks, Today Shelly Kelly pointed out a serious bug in the code that merges spectra. Spectra merged as mu(E) or norm(E) have not ever been calculated correctly. There were several problems -- the worst was that the e0 shifts for all groups involved in the merge were ignored. This resulted in numerous problems with the merged spectra. I think I have fixed the problem -- at least the sample data that Shelly gave me now gets merged correctly. There is a new source tarball on my web site. I also added a couple of trivial features to both athena and artemis. The first is a splash-screen, i.e. something to look at in those endless seconds between double clicking on the icon and having the program spring to life on the screen. I also added several keyboard shortcuts for common tasks in both programs. You can see what these are by examining the menus in the menubar. I also added something new to my web site. Athena and Artemis change much faster than Ifeffit these days. The bad part of this is that Windows users don't get to take advantage of my updates as often as unix and OSX users. So today I added a section to the downloads page with links to the executables of my four programs. I doubt I will update the executables as often as I update the source tarballs. But when I do, I'll post the executables on the downloads page. The idea of these individual executables is that you replace the executable in the C:\Program Files\Ifeffit\ folder with the new one. These executables now found on my downloads WILL NOT RUN CORRECTLY outside the context of a properly installed ifeffit package. But if you have installed Ifeffit using the installer from Matt's web page, you will be able to drop my new executables in place. 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

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