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

merging I0
by Bruce Ravel 02 Jul '03

02 Jul '03

Hi folks, As Matt suggested, I will take a stab at this question. > > I had a question I was hoping you could help me with. I have imported a > > bunch of ASCII type files into Athena and averaged them all together. The > > ASCII files contain the Energy, detector file, I0, I1, and I2. After I > > average the files together, I want to save the file and export it as an > > ASCII file. I understand how to do this, but when I do it I only obtain > > the Energy, [detector/IO], and background in column three (like it states > > in the manual). Now what I want to do, is extract the averaged I0 column > > from the process. Is there anyway to do this or will I just have to > > average I0 in another software. Any help with this would be appreciated. > I believe you'd have to average all the I0 values yourself, and that > athena cannot do this easily. Bruce might correct me on this.... > It would be possible to do this using the Ifeffit commands directly > (including in the athena command window), something like this: Matt's suggeted sequence of raw ifeffit commands is certainly a fine way of doing what Jacob asked for. Averaging I0 alone is not something I had in mind when I designed Athena's basic interface features, but it should be possible. As is the case when one tries to explain a sequence of mouse clicks, this will be rather wordy. Sorry.... As all Athena users know, the first thing that happens when you import a data file is to interact with the file selection dialog: http://leonardo.phys.washington.edu/~ravel/software/exafs/images/athena/col… Athena remembers which columns were used to make the numerator and denominator of the expression that constructs mu(E) from the column data. (Note that the ability to make detector groups is lost once the data are saved to a project file. Making detector groups is something that must be done during the session in which the raw data are imported.) In the Group menu is a option for "Make detector groups". This will make entries in the Data groups list for the numerator and denominator used to make the original data group. So my solution to Jacob's problem was to import data files one-by-one. Each time, I made the detector groups. Once all the data was imported and the detector groups were made, I marked the denominator groups (my test data were all transmission, so I0 was in the denominator). Then, in principle, one could select "Merge marked data in mu(E)" from the Merge menu and have the merged I0 data that Jacob was looking for. *In principle*. In fact, there is a bug in the current version of Athena and the merge of the I0 data failed. That bug will, however, be fixed soon. Once that is done, it will be possible, albeit inconvenient, to merge I0 data as Jacob wants. You may wish to try working through the procedure that I described to understand how the detector group feature of Athena works, even if the final step will fail in the current version. B P.S. I am pretty certain that this will be fixed in time for the next release of Athena and that the next release will be before Friday the 11th. -- 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: your mail
by Matt Newville 02 Jul '03

02 Jul '03

Hi Jacob, Jacob Shokes (jshokes(a)chem.uga.edu) wrote: > I had a question I was hoping you could help me with. I have imported a > bunch of ASCII type files into Athena and averaged them all together. The > ASCII files contain the Energy, detector file, I0, I1, and I2. After I > average the files together, I want to save the file and export it as an > ASCII file. I understand how to do this, but when I do it I only obtain > the Energy, [detector/IO], and background in column three (like it states > in the manual). Now what I want to do, is extract the averaged I0 column > from the process. Is there anyway to do this or will I just have to > average I0 in another software. Any help with this would be appreciated. Sorry for the delay - I was away at the EXAFS conference, and am still catching up on email. I hope it's OK that I forward this question to the ifeffit mailing list, as others might have similar questions, and Bruce Ravel might have a better answer. I believe you'd have to average all the I0 values yourself, and that athena cannot do this easily. Bruce might correct me on this.... It would be possible to do this using the Ifeffit commands directly (including in the athena command window), something like this: read_data(mydat.001, group=a001, label='energy if i0') read_data(mydat.002, group=a002, label='energy if i0') read_data(mydat.003, group=a003, label='energy if i0') ave.energy = (a001.energy + a002.energy + a003.energy ) / 3 ave.if = (a001.if + a002.if + a003.if ) / 3 ave.i0 = (a001.i0 + a002.i0 + a003.i0 ) / 3 write_data(file= ave.dat, ave.energy, ave.if, ave.i0) In most cases I don't think you really want to do this, or use an averaged I0 signal. For EXAFS data in transmission or fluorescence (or electron yield), log(I0/I1) or IF/I0 can be averaged and merged, but averaging I0 may not be meaningful. On the other hand, you might be looking for typical I0 count rates, and the variations in I0, in which case such averages might be useful. Hope that helps, --Matt

1 0

a limitation of Athena, Artemis, and Ifeffit
by Bruce Ravel 17 Jun '03

17 Jun '03

Hi folks, An irritating limitation of the codes was just brought to my attention. My colleague here at NRL had his data file in a deeply nested folder and each folder name was long and descriptive. The end result was that the fully resolved file names (i.e. path and name) was many dozens of characters. When he tried to import these data into Athena, Athena failed silently. That is, Athena failed to import the data and failed to report a reason why. The reason is that there is, in ifeffit, a limit to the total number of characters for the fully resolved filename. My colleague, with his long, descriptive folder names, had exceeded this limit. In that situation, the current version of Athena (and Artemis, as well) fails silently. In the next versions of the codes, they will issue a warning if your fully resolved filename is too long. For the moment, however, the best I can do is to make you all aware of the problem and to suggest either short folder names or placing your data high up in the file tree. 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 0.8.020 and artemis 0.6.005
by Bruce Ravel 16 Jun '03

16 Jun '03

Hi folks, Just in time for the XAFS conference, I am announcing new releases of Athena and Artemis. There are not many major new features this time, but there is a long list of bug fixes and usability enhancements. If you have not yet upgraded to Ifeffit 1.2.1, you should do so, then download the latest versions of my codes. As always, new source code tarballs and windows executables can be found on my downloads page. For those Windows users new to the mailing list, I'll explain how to install the new executables. It's quite simple. Grab the .exe files from my downloads page and drop them in the C:\Program Files\Ifeffit\ folder on top of the old versions. If you installed to some other location, then drop th new executables there. Doing this is enough to leave the desktop and Start Menu icons functional. The one major new feature in Artemis is the ability to set restraints on your parameters. It's as simple as setting a math expression on the "Guess. Def, Set" page and flagging the parameter as a restraint. The restraint defined this way will then be used in the fit. If you are interested in using restraints, you should read the following: http://cars9.uchicago.edu/ifeffit/refman/node55.html http://cars9.uchicago.edu/xafs/Advanced_Methods/BNLworkshop2001/newville.pdf There is an example project file using a restraint in the source code tarball which follows very closely the restraints example from the ifeffit source code tarball. There really are a lot of improvements this time around and it is well worth updating. Check out the change logs on my web site for all the details. The acknowledgment list is a long one this time. Among those with helpful bug reports and good suggestions: Scott Calvin, Vince Harris, Dale Brewe, Adam Webb, Mark Jensen, Paul Fons, and Grazia Proietti. Thanks to all of you. The award for the loopiest suggestion which I had no good reason to refuse goes to Mark Bondin, who wants to use Athena for background removal and Xfit for data analysis! B P.S. There are a few of you who have expressed an interest in using Artemis to analyze your DAFS data. It was pointed out to me that I had forgotten to include the dphase path parameter in Artemis. That has been fixed, although the dphase parameter is hidden along with the k_array, amp_array, and phase_array path parameters. If you want to use dphase or any of the other three "hidden" parameters, go to the Paths menu and click on the button at the bottom of the menu that reads "Extended path parameters". When you click it on, text boxes for dphase and the _array path parameters will be displayed on the paths page in Artemis. P.P.S. I am giving a poster about Athena and Artemis at the XAFS conference. My time is Wednesday during the 16.15 to 17.45 session. If you'll be at the conference, stop by and say hi. I'd enjoy meeting those of you I don't already know and would enjoy catching up with those I do. -- 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

XAFS 12
by Matt Newville 07 Jun '03

07 Jun '03

Hi Everyone, Many people on this list will be at the upcoming XAFS 12 conference, and have probably seen the notice for the microsymposium on XAFS analysis programs. Bruce will talk about the 'Ravelware', I'll talk about Ifeffit etal, and several real luminaries in the field will talk about XAFS and XANES analysis. The conference is a great chance for many informal discussions about the ifeffit programs. At this point, there are many possible directions for development and improvement and I (and I assume Bruce and Sam) would love to hear feedback on what the priorities for new functionality and development should be. It might be good to set aside a lunch time (or beer-time?) to talk about development priorities. I'd tenatively pick Thursday lunch (after the analysis symposium and most posters/talks to be able to learn some things from the conference), but maybe we can finalize the time and place at the Tuesday evening analysis symposium. A few possible topics of discussion are 'Installation on MacOS X' and 'Getting GUIs that run Feff6', but there may be other issues. If you're interested, please feel free to join the discussion, and see you in Malmo! --Matt

1 0

ifeffit 1.2.1
by Matt Newville 28 May '03

28 May '03

Hi again, Well, it was supposed to be the 'stable' release, but a few large bugs were noticed quickly in ifeffit 1.2.0: - Feff6L didn't make it past the pathfinder before dying. - some of the output arrays for feffit() with multiple k-weights were still messed up. These turned out to be easy to track down (and the Feff problem was all mine -- not native to Feff!!!), so I fixed these to make version 1.2.1 (both source and Window exe), which is now available at http://cars.uchicago.edu/ifeffit/download.html and at Sourceforge: http://sourceforge.net/project/showfiles.php?group_id=80919&release_id=1603… It usually takes a day for Sourceforge's mirrors to get new files. Since this is supposed to be the 'stable' version, I don't intend to be making releases every 5 days. These problems were big and easy to fix, and I'll be away for a week so thought I should post these now. Really, it will calm down. As others have suggested, I like the idea of being able to update the individual files (athena.exe, ifeffit.dll, feff6l.exe) to an already-installed Windows tree. It should be fairly easy to write a program that looks at some webpage for a zip file with the changes since version "1.2.X" and update the needed files. --Matt

5 10

TkAtoms weirdness
by Carlo U. Segre 23 May '03

23 May '03

Bruce: I have recently encountered a weird problem with TkAtoms. Let me detail it setp by step. 1. Start TkAtoms and build a model from scratch. 2. Press the "Run Atoms" button. The output of this is correct and can be saved to disk. 3. Save the "atoms.inp" file associated with the model that has been successfully run and exit TkAtoms. 4. Start TkAtoms again and load the previous "atoms.inp" file. 5. Press the "Run Atoms" button again. This time the output (the FEFF input file) is completely different than in step 2. It is also completely incorrect. Many of the x,y,z coordinates are set to zero. In fact the x coordinate is always zero. If I clear the data boxes and re-enter the original numbers, the results are correct once again. This is extremely confusing to me. I have only tried it with a single structure but it shows this behavior consistently. I have attached the offending atoms.inp file. Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Research, Armour College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre(a)iit.edu http://www.iit.edu/~segre

3 2

Re: fitting with artemis
by Bruce Ravel 22 May '03

22 May '03

Gleb, I trust you will not mind if I CC my answer to your question to the Ifeffit mailinglist. It is, I think, of sufficiently general interest. > How can I constrain a guess parameter to some limited range of > values during a fit? For example during a fit I want my DW factor > be varied but in the limited range, e.g. from 0.002 to 0.01? In the > ifeffit doc I hav'nt found a math expression for confining a guess > parameter. There are two possible answers. 1. To constrain a value as you wish, this will work: guess x 0.005 set y max(0.002, min(x, 0.01)) That idiom will require the value never to be smaller than 0.002 and never larger than 0.01. A caveat: If, without this constraint, the fit wants that parameter to become too large or too small, than the likely result of this constraint is that the value will be pinned at one end or the other. The min/max idiom often does not behave as you'd like. 2. The other option is to use a restraint as described in the Ifeffit reference manual: http://cars9.uchicago.edu/ifeffit/refman/node55.html Artemis does not yet have an interface to setting and using restraints, but you could use Artemis to write and save an ifeffit script, add the restraint by hand, and then run the ifeffit script from the command line. The ability to add restraints to a fit will soon be handled well by Artemis, though. HTH, 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

background subtractions
by Bruce Ravel 19 May '03

19 May '03

Hey Carlo, Here is my answer to your other two questions, also CCed to the mailing list. > 2. What is the justification for fitting the background during the fitting > process. I understand that it is important to remove background large k > oscillations but it seems to me that this is better done without the bias > of simultaneously fitting FEFF shells. I know that Steve Wasserman and > Jeff Terry have a Mathematica background subtraction algorithm which > allows you to back FT the region below Rbkg and subtract it from chi. > This seems to be roughly the same idea as the background fit but is less > biased by the fitting. I would appreciate your comments. Also, is this > now a part of FEFFIT or is it solely in Artemis? It is roughly the same idea, but I would say that you *want* the background to be biased by the fitting. The issue here needs to be restated in terms of what is meant by "a good background removal". Implicit in the back transform algorithm that you describe is the assumption that a good background removal makes the low-R region "look pretty". That is, one assumes that the low-R regions should tail away in some monotonic fashion. Basically, this is an esthetic argument rather than a statistical or scientific argument. On some level, subtracting away a portion of the spectrum via a back transform algorithm is not horribly different from modifying the plot of the chi(R) spectrum with Photoshop or The Gimp. First off, I should explain how the background co-refinement in Ifeffit works. You define a lower bound of the fitting range in R-space. This Rmin value takes the role of Rbkg in the autobk algorithm. That is, Rmin is the cutoff in R-space above which you will use Fourier components from feffNNNN.dat files to fit the data and below which you will use a spline to fit the data. The spline is determined in exactly the same way that the spline in autobk is determined. Is this cheating in terms of number of `independent' point? No. The splin has exactly the number of knots corresponding to the band whose width in R is from 0 to Rmin. That is, different information is used by the spline than by the rest of the fit. Why is another pass of the autobkl algorithm needed at this stage? Why couldn't autobk just do the job correctly up front? Well, this is sort of a numerical issue. Autobk has a really hard job to perform. If you Fourier transform the entire mu(E) spectrum, you will find that the Fourier contribution from the mu0(E) function is much much huger than the contribution from the chi(K) function. Thus autobk is attempting to isolate something small out of something large. By the time Artemis sees the data, mu0(E) is all gone. Further refining the background is thus a matter of separating something small from something small. The REAL REASON to do the background co-refinement is because Ifeffit (and thus Artemis) will report on the **correlations between** the background parameters and the things you are really interested in, such as delta_R and sigma^2. This is improtant. Even more it is a way of defining "goodness" of a background removal that removes esthetic concerns. A "well-removed" background is one that is not too highly correlated with the fitting parameters. Of course, "not to highly" is a rather subjective, but it atleast is a number to work with. So what is the right value of Rmin? Well, you want to choose an Rmin that is high enough to make a pretty picture (esthetics is not entirely without merit, after all) but low enough so as not to introduce excessive correlation with the fitting parameters. Rmin, therefore, is one of the parameters that you need to fiddle with in your data. For oxides (and carbides, nitrides, etc) Rmin might be quite low. Indeed, there may not be a value which gives a spline that is loosely correlated with the fitting parameters and which also satisfies the esthetic criteria of a pretty low-R region taht tails off monotonically. To avoid harming the data by excessive correlation with the spline, you may be forced to accept low-R peaks even in your published data. Finally, how does this discussion relate to the background removal done in Athena? Well, it should be clear by now that you cannot know the right value of Rmin a priori. You have to do some fits and measure the correlation between the background and the fitting parameters to judge what Rmin should be. Good practice with Athena is to choose a rather low value of Rbkg and not worry that some icky little low-R peaks might remain in the data. If you choose a low Rbkg in Athena, you can always choose a higher Rmin value in Artemis. But you cannot go the other way. You should not choose a value of Rmin that is *lower* than the Rbkg used in Athena because then you will not correctly evaluate the correlations. > 3. When it comes time to report results, is it better to be able to > subtract the background? Is it legitimate to report fitting parameters > without including the "hidden" background parameters? I say yes, it is better to subtract the background found by Artemis. (That's what the "use previous background" button does.) Esthetics, as I confessed above, is still important. And yes, reporting fitting parameters from a fit with a background co-refinement is most certainly legitamate. Indeed, it is more so because you can also report the level of correlation with the background spline. This gives you reader MORE confidence in your results and a better ability to interpret their validity. Sorry I was so long winded, but these are subtle issues. When I give a series of lectures on data analysis, I usually spend about 30 minutes discussing background issues. HTH B PS: Background co-refinement is, like everything else mathematical, something done by Ifeffit. Ifeffit does all the heavy lifting, Artemis just keeps it all organized. -- 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/

3 2

Re: [Ifeffit] Windows Installer for Ifeffit 1.2.0
by Mark Jensen 19 May '03

19 May '03

Bruce, Matt, and the curious: Thanks for clarifying your distribution philosophy. >I think we haven't figured this out yet. Is it OK to download >ifeffit-1.2.0.exe as the basic installer, and then install >whatever updates to athena/artemis may exist on top of that? >>I thought that people were, by and large, happy with the solution of >>dropping new athena & artemis exes on top of the old ones rather than >>downloading the 30MB installer every time I make an update. Since I I very much like the current system of being able to 'plug-in' new versions of Athena and Artemis exe's as they are made available. I just wasn't sure if that approach was being abandoned. >>In any case, either you got confused updating or we got confused >>building the installer. It *was* our intention that the new installer >>have Athena 0.8.019 and Artemis 0.6.004. As far as what happened in the installation goes I'm not sure who was confused. Maybe I was pushing the installer a little too hard: I definitely chose the correct program to install Ifeffit 1.2.0 because: 1) Its filename is 'ifeffit-1.2.0.exe' which makes the choice pretty obvious 2) Ifeffit 1.2.0 was installed 3) When I repeated the procedure on Monday morning, making absolutely certain that I used ifeffit-1.2.0.exe, I was still left with Athena 0.8.015 and Artemis 0.5.008. (Those must have been the most recent versions of Athena and Artemis that I was using on that computer... I thought I was more up to date.) As I have done for Ifeffit installations in the past, I did no uninstallation or file deletion before trying the new install and I installed into the same directory as the existing version. When this Ravelware trouble caused me to look more closely at the directory contents, the only files that had May 2003 dates were the *.bat files and the new Ifeffit files. The dates on Athena and Artemis were still March 2003! However, during the install, I saw the installer say that it was unpacking Artemis and Athena. Apparently it did not install over the old versions (but it did install Ifeffit 1.2.0?!). The Solution: So, I uninstalled Ifeffit and deleted the remaining contents of the Ifeffit directory (Keeping my fingers crossed that the new install would work). The ensuing activation of ifeffit-1.2.0.exe now gives me the correct versions of Ifeffit, Artemis, and Athena! Now let's do some fitting. Thanks for your thoughts, Mark ------------------------------ Mark P. Jensen Chemistry Division Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439-4831 USA 630-252-3670 630-252-7501 FAX mjensen(a)anl.gov

1 0

Windows Installer for Ifeffit 1.2.0
by Mark Jensen 17 May '03

17 May '03

Bruce and Matt and everybody else, I am probably missing something, but the Artemis and Athena splash screens from the new Ifeffit 1.2.0 windows installer that I just used say that it installed Athena 0.8.015 and Artemis 0.5.008 and Ifeffit 1.2.0. Initially, I thought that the windows installer would (as in the past) include the latest (and greatest) versions of Athena and Artemis. But now that I think about it more, Matt seemed to indicate that he wants a stable distribution, which might mean older versions of Athena and Artemis. Bruce's website, on the other hand, seems to say that the windows installer for Ifeffit 1.2.0 would have the most recent windows versions of Artemis and Athena. I politely ask, which of these ideas is winning and when can windows users hope for some new versions of the Ravel-ware. Mark Jensen ------------------------------ Mark P. Jensen Chemistry Division Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439-4831 USA 630-252-3670 630-252-7501 FAX mjensen(a)anl.gov

3 2

Re: Ifeffit Digest, Vol 3, Issue 8
by k-kupiecki＠northwestern.edu 16 May '03

16 May '03

John and Bruce, Thank you for your kind help. I'm still a little perplexed... Basically I'm taking SEXAFS on a Ni(110) single crystal substrate (with a fraction of a monolayer of Au which substitutes into the first layer... SEXAFS spectra were obtained at the AuL3 edge). I've taken data in four different posistions: "grazing incidence" with the E vector of the x-rays parallel to the surface normal 1) with x-rays along the (001) direction 2) with x-rays along the (-110) direction and "normal incidence" with the E vector of the x-rays perpendicular to the surface normal (E parallel to the surface plane) 3) with x-rays along the (001) direction 4) with x-rays along the (-110) direction After receiving both Bruce and John's emails I tried three different feff.inp files, using my original hemisphere cluster, each using one of the following: POLARIZATION 1 1 0 or POLARIZATION 0 0 1 or POLARIZATION -1 1 0 but upon ploting out chi(k) vs. k from the chi.dat's for each of these they looked identical... did I miss something? Thanks, Kristine Witkowski Northwestern University > > Hi Kristine, > I basically agree with what Bruce Ravel wrote. We've occasionally done > FEFF calculations on surfaces (e.g. with K. Baberschke and students), > and the key to the calculation is to use appropriate Polarization > cards (and Ellipticity cards) in the calculation as described in the > doc. Please let me know if you have problems doing this. > Cheers, > John >

1 0

1.2.0 windows installer released
by Matt Newville 16 May '03

16 May '03

Hi Everyone, The Windows installer for ifeffit 1.2.0 is now available at the Ifeffit homepage. This is now officially the "stable" version, but I want to stress that there may still be bugs (in fact, there is a serious bug still in Feff6L!!!), and that "stable" means that changes to the core library will attempt to follow the principle of "first, do no harm". Also, the sourceforge.net site for Ifeffit now has the latest versions of the stable source and windows executables at http://sourceforge.net/projects/ifeffit/ --Matt

1 0

new versions of Athena and Artemis using Ifeffit 1.2.0
by Bruce Ravel 16 May '03

16 May '03

Hi folks, Today I posted a new source code tarball for Athena and Artemis to my web site. I did *not* post new Windows executables, however. Linux, Unix, and OSX users should first upgrade Ifeffit by grabbing the Ifeffit 1.2.0 tarball from Matt's web site and then grabbing the tarball from my web site or run the horae_update script. Windows users should wait until Matt announces the new Windows installer (which is almost ready to be released) and download that. Future Windows executables of Athena and Artemis will assume that you have already updated the base Ifeffit package. New stuff this time: 1. The horae_update script is a bit smarter in that it compares the version on the server to the version on your computer and does nothing if you seem to be up to date. 2. New features of Ifeffit 1.2.0 are used, such as rebinning in Athena and fits in Artemis with multiple-data-sets, multiple-k-weights, and/or background co-refinements. 3. Better reporting of ill-posed variables in Artemis (based on Ifeffit's reporting of the same). 4. Better reporting of best-fit path lengths after a fit finishes. 5. Check for mismatched parentheses in math expressions in Artemis (a HUGE problem in prior versions). 6. Examples of multiple-data-set fits in the form of artemis project files. Look for the files examples/artemis/EuTiO3/eto.apj and examples/artemis/Cu/temparatures.apj in the source code tarball or C:\Program Files\Ifeffit\examples\EuTiO3\eto.apj and C:\Program Files\Ifeffit\examples\Cu\temparatures.apj on Windows. Be sure to read the comments in the project journals of those two files. + several bug fixes 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

Artemis questions
by Bruce Ravel 16 May '03

16 May '03

Hi Carlo, Hope you don't mind my responding to the list. These are questions that I think will be of general interest. I am actually going to split my answers into two emails, both of which will still be rather long -) > I have been working with Artemis over the past few days and I have a > couple of questions that I cannot seem to find answers to in the manuals > for FEFFIT and Artemis. OK! You have me up against the wall ;-) Documentation is currently the Artemis' great shortcoming. I apologize that the doc is coming along slowly. FWIW, I have been thinking alot about the doc, but haven't found a lot of time to write. > 1. What is the difference between a SET and a DEF quantity. I suspect > that it is an issue of being updated or not but I am not sure. A SET parameter is evaluated at the start of a fit and remains invarient throughout the fit. A DEF parameter is re-evaluated at every iteration of the fit. Typically a def parameter depends on one or more guess parameters. Let's consider a simple example. Suppose that we have a crystal with a nominal lattice constant "a0" and we want to consider the possibility in the fit that the actuall lattice constant deviates from "a0". To do so, we may consider a parameter "delta_a": set a0 3.61 guess delta_a 0.0 Now suppose we want to use "a" (the measured lattice constant) in math expressions for some of our path parameters. Do we say set a a0 + delta_a or def a a0 + delta_a ? The answer is the second one. If make "a" a SET parameter, then a will be fixed to 3.61 at the beginning of the fit and not change. If, however, we make "a" a DEF parameter, then it will be updated every time that "delta_a" is updated during the fit. At the risk of confusing the issue, I feel I should make a connection with Matt's old feffit program. In the old feffit, set parameters behaved like Ifeffit's def parameters. That is, in the old feffit, set parameters were updated throughout the fit. As a rule of thumb for Artemis, if your parameter is a number, make it a set parameter. If it is a math expression, make it a def parameter. HTH, 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

Anyone out there do SEXAFS?
by k-kupiecki＠northwestern.edu 15 May '03

15 May '03

HI, I'm trying to analyze my SEXAFS data... if anyone out there has done this before could you please drop me a line at k-kupiecki(a)northwestern.edu.... I could really use someone that I can directly question and bounce procedures off of.... Inparticular I'm currently looking for suggestions for how to simulate with FEFF SEXAFS in the "grazing incidence" orientation (with the E vector of the synchrotron beam close (~0.2 deg) to the surface normal of the sample (incident beam ~.2 deg incident on surface). Thus far I've been trying to analyze my samples with SEXAFS taken from a "normal geometry" (~0.2 angle incident to the beam and the E vector of the synchrotron beam in the plane of the surface)... I managed to simulate this with FEFF by giving it a hemispherical cluster representing my surface... But I'm a little confused what I need to change in FEFF to replicate the information coming from just the inter planar bonding (in "grazing incidence") instead of both inter and intra planar bonding as found in the "normal incidence" situation.... Any suggestions would be greatly appreciated! Thanks, Kristine (Kupiecki) Witkowski Northwestern University

3 2

FEFF6 errors?
by Carlo U. Segre 15 May '03

15 May '03

Matt: I have been having problems with the FEFF6 that is distributed with Ifeffit. If I try to run the executable with the feff.inp the TEST directory, it gives the following output ---- copper Calculating potentials and phases... free atom potential and density for atom type 0 free atom potential and density for atom type 1 overlapped potential and density for unique potential 0 overlapped potential and density for unique potential 1 muffin tin radii and interstitial parameters phase shifts for unique potential 0 phase shifts for unique potential 1 Preparing plane wave scattering amplitudes... nncrit in prcrit 9 Searching for paths... Rmax 0.0000 keep and heap limits 0.0000000 0.0000000 Preparing neighbor table nfound nheap nheapx nsc r Internal path finder limit exceeded -- path list may be incomplete. Paths found 0 (nheapx, nbx 1 0) Eliminating path degeneracies... Plane wave chi amplitude filter 2.34% STOP no input statement executed ---- It only generates the 4 files: geom.dat paths.bin paths.dat phase.bin If I look at paths.dat, I see: ---- copper Rmax 0.0000, keep limit 0.000, heap limit 0.000 ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ Plane wave chi amplitude filter 2.34% ------------------------------------------------------------------------------- ---- I am a bit confused about this because when building the Debian package, everything compiles properly and all the libraries seem to be there properly. Any ideas? Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Research, Armour College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre(a)iit.edu http://www.iit.edu/~segre

2 1

Athena - plotting limits
by Carlo U. Segre 15 May '03

15 May '03

Bruce: Why does Athena only plot from 0-15 in k-space even though there is data beyond that. Now that I look back at the mu(E) plots, they are restricted in energy too. I understand that we would normally not use data to far beyond k=15 but it still might be nice to see it. Perhaps, I am just not seeing some kind of parameter that could be set? Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Research, Armour College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre(a)iit.edu http://www.iit.edu/~segre

2 1

ifeffit 1.2.0
by Matt Newville 14 May '03

14 May '03

Hi Everyone, At the suggestion of several people, I've repackaged the latest version of Ifeffit and called it version 1.2.0, to indicate that this is the stable version. By this, I mean that bugs and errors will be fixed in this series, but that no new features will be added. As of now, only the source kit for ifeffit-1.2.0 is available from the Ifeffit web site. The Windows installer package should be available within a few days. In addition to this, it was recommended to start using the SourceForge.net services. This will happen, and an empty page for Ifeffit is available there at http://sourceforge.net/projects/ifeffit/ It may take much of the summer to get this working completely. This will provide multiple download sites with mirroring. In addition, the development/unstable versions will be available through Sourceforge's CVS server -- if anyone is interested in this, letting me know! There are other services (such as bug tracking) available from Sourceforge as well, and it is possible that the mailing list may eventually move to sourceforge.net as well. Thanks, --Matt

1 0

upcoming EXAFS course at NSLS
by Bruce Ravel 12 May '03

12 May '03

Hi folks, It occurs to me that not everyone who reads this list is or ever has been a user of NSLS, so you may not be aware of an upcoming event. This summer, Simon Bare and I are running a course on EXAFS Data Collection and Analysis at the NSLS. The course will be July 14-17 and will include lectures, beamline practicals, and lots of time in front of computers using atoms, feff, ifeffit, athena, and artemis. The speaker list includes eight 75 minute lectures on a variety of topics covering most aspects of XAS measurement and EXAFS analysis. The speaker list is really great this year and includes some familiar names from our little list, including Matt, Simon, Shelly Kelly, Scott Calvin, and John Rehr. Last year's course was lots of fun for everyone involved. Here is the URL: http://nslsweb.nsls.bnl.gov/nsls/org/workshops/exafs/exafs_workshop.htm We have limited space and received about a factor of two too many application last year. Still, it would be great to see some of you folks this summer at the NSLS! Or you might pass the URL along to someone else in your research group who is looking for an intense but fun introduction to XAFS. 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: [Ifeffit] Re: ifeffit_1.0077 compilation problem
by Carlo U. Segre 09 May '03

09 May '03

Matt: I very much like the idea of a "stable" and "testing" line for the programs. I could keep both of them updated in my Debian packages. Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Research, Armour College 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] Re: ifeffit_1.0077 compilation problem
by SCHLEGEL Michel 177447 09 May '03

09 May '03

Dear Everybody, > I can then start a beta series for new features and build > systems, and expect only beta testers to be affected. Any > comments on this? Just a suggestion (discard it right away if it looks like it will take too much time): Why not copying the well-proved Linux bumbering of versions, and reserve odd numbers for test versions, and even numbers for "stable" versions? This would allow simple laymen to benefit from the outstanding capabilities of Ifeffit, while allowing the "clergy" to summon the debugging deities on well-iddntified newborn versions... Best regards, Michel Schlegel

1 0

Re: ifeffit_1.0077 compilation problem
by Matt Newville 08 May '03

08 May '03

Hi Paul, I'm responding to this one on the mailing list. As many people have noticed, there are several problems with the 1.0077 distribution of Ifeffit. It seems that it should be treated as a 'test' version. Most of the problems are small from my end (that is, easy to fix, even if show-stoppers for functionality or building). I'll be changing the links to ifeffit.tar.gz to point to versions ifeffit-1.0077a.tar.gz, ifeffit-1.0077b.tar.gz, .... over the next few days for testing. If you're brave, you can try the latest test version and let me know what's not working. Otherwise, we should have a stable, working 1.0078 sometime next week, possibly with some of the wrappers using some of the new features. As more people are using Ifeffit/Athena/Sixpack for real work, it seems that having a stable version is good idea. So I'm leaning toward calling the next release (ie, 1.0078) Ifeffit-1.100 and only fixing bugs, and build problem for this version so that this can be the 'stable, recommended' version, and can get better tests and documentation to really reflect this stable version. I can then start a beta series for new features and build systems, and expect only beta testers to be affected. Any comments on this? On Thu, 8 May 2003, Paul Fons wrote: > In attempting to compile 1.0077 of ifeffit, I encountered some > unresolved symbols. A grep search seems to indicate that atomic.f has > the definitions, but it doesn't seem to be in the macosx makefile. > Any suggestions? Yes, two suggestions: 1. Run 'configure; make ' work from the base ifeffit directory. If this doesn't work, please let me know what fails. I'd much refer this to work, and it seems close. 2. Change line 134 of src/macosx/makefile.in to read $(srcdir)/iff_unguess.o $(srcdir)/iff_window.o $(srcdir)/atomic.o and re-run 'configure ; make'. > I am doing the build using the Makefile in src/macosx. One more thing, > under 10.2 I had some problems with overlapping definitions in multiple > libraries (in Apple's and Fink). The solution was to delete the "-l > termcap" as well as the "-L/usr/lib" from the library options in the > makefile. As I have yet to get things to link successfully, I will > send you the final modifications when I resolve the symbols (at_kedge, > etc.) problem. Which is the preferred version: Apple's or Fink's? Is there any hope of getting a binary distribution for Mac OS X or at least clear and complete instructions for how to do a complete installation using Fink? --Matt

2 1

ooops!
by Bruce Ravel 05 May '03

05 May '03

Hi all, Matt pointed out to me that I forgot to increment the version numbers of Athena and Artemis in their source codes. Thus, when the splash screens appear at start up, they each report a version number that is 1 too small. For instance, the current version of Athena is 0.8.018, but the splash screen says 0.8.017. Silly me. Rather than fix this problem, I'll just make a new release at the end of the week that makes use of some of the nifty news features of Ifeffit 1.0077 which Matt released today. And this time I'll try **really really** hard to get the version numbers correct.... ;-) 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

ifeffit 1.0077
by Matt Newville 05 May '03

05 May '03

Hi Everyone, I've just posted Ifeffit version 1.0077. It's been a while since the last release, and there have been several changes and improvements. The highlights are: - The spline() and bkg_cl() now uses a new rebinning/interpolation algorithm to convert data from chi(E) to chi(k). For finely-spaced energy data such as from QEXAFS measurements, this averages over all energy points within the corresponding k range. For data that isn't finely-spaced, a three-point interpolation is used (as before). There is also a rebin() function that works like other interpolation functions: new.y = rebin(old.x, old.y, new.x) which will use the the same algorithm. Again, this is not normally needed, as spline() and bkg_cl() do this as well. - feffit() now supports multiple-k-weights in a single fit: feffit(..., kweight=2, kweight=0, kweight=4,...) That is, listing multiple values of 'kweight' will use all of them (up to the first 5). Each portion of the fit will be properly weighted, but the error bars reported for such fits always reflect the fact that only 1 data set is really is used (and if 'bkg=true' is used, only 1 set of bkg parameters will be used). The output arrays generated for this form of multiple-k-weight fits will use the FIRST kweight listed. Other outputs will have to be created explicitly. - other improvements to feffit: feffit(bkg=true) now works with multiple-data-set fits. feffit() and minimize() now list 'bad variables' after a fit for which error bars could not be estimated. feffit() now produces correct chi(R) data when input chi(k) data is not on a k=0.05Ang^-1 grid. feffit() with multiple-data-set fits now looks closely to see if repeated data is used, to avoid 'double counting' for N_idp. - f1f2() now looks up and uses the 'known core-width of an edge' by default. That is, if the atom given has an edge energy in the supplied energy range, the corresponding core-width is used. Of course, you can still supply a value for 'width'. Other improvements to f1f2() were made in the Lorentzian convolution, and the precision of the Cromer-Libermann data. - read_data() no longer sorts on the first column by default. - plotting improvements: plot() now interprets 'key=""' correctly (ie, 'no legend') plot(reset) now works to reset the color/style tables. Notes on the windows installation: - I included the latest versions of athena, artemis, and sixpack as of this morning (05/05/2003). - Source and binary installers for the Ifeffit Python module are included in wrappers/python. - I tried (briefly) to build sixpack with python2.2, but ended up installing the binary sixpack from Sam's' web page. Sixpack uses python2.1, which is fine, but clashes with python2.2. To avoid version conflicts, I put sixpack in a completely separate directory 'sixpack'. The batch file and icons point to that version. This means some duplication of files, so we may eventually want to move uniformly to python2.2. - The executables for feffit.exe and autobk.exe have been updated. These should a) write output files more reliably, and b) auto-sense RDF files better. This last feature is not extensively tested. There are lots of changes in this version, and so plenty of room for mistakes. Please give this version and these new features a try and let me know if there are any problems. And, as always, suggestions for what to include in the next version are welcome. Thanks, --Matt

1 0