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

artemis development in the near future
by Bruce Ravel 28 Jul '04

28 Jul '04

Hi folks, As some of you may know, I have been planning for a while to fork Artemis into two branches -- stable and development. It's going to work something like this: * The current version (0.7.008) will be the stable version. (Yes, I am fully aware of the irony of calling any version of Artemis "stable". ;-) For the next couple of months the feature set of stable Artemis will not change. I will only be fixing bugs as they become known. This will be the version recommended for most users. * The current version will be the base of the development version. I will add new features to this branch. Hopefully there will be enough users of the development branch that these new features will be sufficiently exercised as I get them written. * At some point I will decide to freeze the development branch and shift it down to the stable branch. That way, new features will eventually become available to the users of the stable branch, but only after they have been tested for a while. Hopefully, that will avoid some of the troubles we have had since version 0.7.000. * I will promise to make windows executables for every release of the stable branch. I won't promise to do so for every release of the development branch. * I haven't quite decided how to deal with numbering, but the stable branch will continue incrementing the minor number. The development branch will either start at 0.8.000 or at 0.7.500. In either case, the horae_update script will be modified to update either branch. * Windows users who would like to be involved with the development branch should consider installing ActiveState's perl distribution on their computers as that would allow you to test the source code as it becomes available. If anyone is interested in this, I can help get you started. But I would encourage only the enthusiastic to consider this. Most users will prefer to use the executables that I will build for the stable version. * I am not planning to fork any of my other programs. Specifically, I do not see a benefit to forking Athena. Finally, here is a partial list of features that are on the drawing board for the development branch: 1. Update the atoms page to use an interface modeled on the new GDS page. 2. Enhanced functionality of the feff interpretation page 3. Keep a history of all fits run. This will allow such things as over-plotting of different fits with the data, comparison of the log files from different fits, and so on. 4. Generation of math expressions for delta_R based on the crystal parameters used in atoms. 5. Import of CIF files. 6. Import of PDB files and conversion to feff.inp format. 7. A bunch of internal modifications that will not be user visible but will support some of the changes above and will need extensive testing. OK, that's all the news that's fit to print. I hope that people are downloading and trying out the new release. B -- Bruce Ravel ----------------------------------- ravel(a)phys.washington.edu Code 6134, Building 3, Room 405 Naval Research Laboratory phone: (1) 202 767 2268 Washington DC 20375, USA fax: (1) 202 767 4642 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b 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

horae 038 Debian packages
by Carlo U. Segre 28 Jul '04

28 Jul '04

The horae packages for Debian have been built and are at my apt repository. Cheers, Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate 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] artemis development in the near future
by Jensen, Mark P. 28 Jul '04

28 Jul '04

Michel is right Bruce! We need a Ravelware reference to cite. That is a major bug! ------------------------------ 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 > -----Original Message----- > From: SCHLEGEL Michel 177447 [mailto:schlegel@azurite.cea.fr] > Sent: Wednesday, July 28, 2004 10:48 AM > To: 'XAFS Analysis using Ifeffit' > Subject: RE: [Ifeffit] artemis development in the near future > > Bruce, > > > * Windows users who would like to be involved with the development > > branch should consider installing ActiveState's perl distribution > > on their computers as that would allow you to test the > source code > > as it becomes available. If anyone is interested in this, I can > > help get you started. But I would encourage only the > enthusiastic > > to consider this. Most users will prefer to use the executables > > that I will build for the stable version. > > Well, to paraphrase some recent declaration, sometimes you > have Activestate, sometimes, you haven't, there's this little > third category... > > Yes, I have installed ActiveState a long time ago, but that > was just to run some script, and it is unclear to me if you > plan to run the development versions of Athena and Artemis as > script, or if you will ask each and every Windows user to > compile his/her own little executable. In the later case, > You'll have to explain me. > > Othervise, the new version runs fabulously great, apart from > a minor point: > I can't fit simultaneously several spectra (polarization > data) in q-space. > TApparently Artemis traps some kind of error message. but the > software keeps on running. > > Otherwise, there's a little practical point which bothers me: > when it comes to publishingand citing, we know how to shower > praise on Matt, but we are still yearning for some sound > reference for the Ravelware. > Is there any chance that this 'bug' will get fixed in the near future? > > Best regards, > > Michel Schlegel > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit >

2 1

Ifeffit 1.2.6 for Windows
by Matt Newville 27 Jul '04

27 Jul '04

To follow up on Bruce's announcement: The full installer for Windows is now ready and available from http://cars9.uchicago.edu/ifeffit/download.html The Windows installer includes Ifeffit 1.2.6, and the latest versions of SixPack (0.50) and Horae (that is, Athena 0.8.030, Artemis 0.7.008, Hephaestus 0.04, and TkAtoms 3.0beta9), and can be downloaded either from the cars.uchicago.edu server or from the sourceforge.net server. An update for Windows (update #10) is also available, though this update is relatively large (~12Mb: almost half the size of the installer itself!). For those of you who are using the programs regularly, it may be worth the effort to download the full installer. --Matt

1 0

RE: [Ifeffit] Re: Artemis Question
by Kelly, Shelly D. 27 Jul '04

27 Jul '04

Hi John, I have a couple of comments to add to Bruce's reply: Feff is truly amazing. You can take a crystal structure for a Metal-oxide and apply it to a hydrated metal atom in solution with great success. -You can also do other non-physical things to the feff list of atoms and apply it to a real problem. There are a couple of thing to keep in mind. 1) Feff needs to have a list of atoms that extends well beyond the paths that are actually used in the fit. Always pad the feff.inp file by at least an Angstrom. If you are using feff calculation for the first time. Pad the feff list by one angstrom and then by two angstroms and check that the paths that you are going to use are the same. You do not want to use paths from the edges of the cluster that you give to feff in the feff.inp file. -Hence you need to use a structure like a metal-oxide to model a hydrated metal. 2) If you think that you have some unique geometry, linear multiple scattering paths then you need to be more careful to get these paths correct in the feff.inp file since they will have unique scattering amplitudes. 3) If the actually distance for the path included in the fit is different from the starting distance as given by the feff list, then you need to re-run the feff calculation. If you are just playing around you can move the paths by 0.5 Angstroms to get an idea that the path will work. In the final published fit, I like to see the change in the path length much less than this. If you are looking at solutions a great place to start is with the metal and the metal-oxide. Shelly > -----Original Message----- > From: Bruce Ravel [mailto:ravel@phys.washington.edu] > Sent: Tuesday, July 20, 2004 5:40 PM > To: XAFS Analysis using Ifeffit > Cc: John Butler > Subject: [Ifeffit] Re: Artemis Question > > > On Sunday 18 July 2004 11:38 pm, John Butler wrote: > > Basically, the problem that I'm having is that the system > I'm working > > on is a solution (to start I'm trying to look at a solution of Zinc > > Sulfate and then look at data with other components we're > interested > > in). Unfortunately, the part of the manual dealing with solution > > analysis hasn't been written yet, and the people I know who > use EXAFS > > don't do anything with solutions. > > > > I was hoping that you could point me in the right direction > for how to > > proceed with the analysis (e.g. is there anywhere I'm > likely to find > > the FEFF files ... is there a 'standard' way to attack this kind of > > problem). Of course I assume you're a pretty busy guy and have > > neither the time nor inclination to give me a detailed step by step > > guide or anything ... I was just hoping you could point me in the > > right direction, give me a couple of tips, and/or show me where to > > look. > > John, > > As you can see, I have forwarded you question along with my > answer to the > Ifeffit mailing list. > > You are correct to assume that I'm a busy guy. This week > (like each of the > other weeks this month) I am at NSLS collecting some data and > helping our > users. Fortunately, the mailing list is a solution to the > "busy expert" > problem. Enough people read and respond to the mailing list > that someone > should be available to answer just about every question. > > I doubt, actually, that you problem is really so hard to get > started with.. > Lots of problems in XAFS do not fall into nice little pigeon > holes. One > knows how to deal with data on an iron foil because one knows > what the > structure of iron metal is. Most real research problems, > obviously enough, > are problems precisely because the structure is not perfectly > well known. > > In the case of a solvated complex, there is probably some > sort of analogue > which can be used as a starting place. Perhaps there is some similar > compound whose structure *is* known. Perhaps your solvated > complex has a > crystalline form that is similar, at least in the local > environment, to the > solvated form. In any case, find something that is similar > to your real > material. Run feff and compare to the data. Perhaps your > analogue structure > will be close to your data. In that case, you should be able > to parameterize > the feff calculation in such a way that you can begin to > understand the ways > in which your complex differs from your analogue. > > Perhaps the analogue structure is a very poor match for the > data. That in > itself is information, in that it tells you to go look for a > different > analogue. > > The common theme to what I have said here (and indeed to any > analysis problem) > is that you make some educated guesses as to what you real > sample looks like. > You test those guesses. If they seem to be leading you in the right > direction, super. If not, make new (and newly educated!) guesses. > > My other piece of advice would be to spend some time fitting > known spectra. > If you are new to XAFS, then you are learning two things at > the same time: > how to interpret XAFS data and how to use my and Matt's > screw-ball analysis > programs! I consider it a good idea to spend some time > fitting data for > which you know the answer so that you can learn how to use > the codes before > plunging into the harder but more interesting problem of your > own research. > > Good luck and join the mailing list, > B > > > -- > Bruce Ravel ----------------------------------- > ravel(a)phys.washington.edu Code 6134, Building 3, Room 222 > Naval Research Laboratory phone: > (1) 202 767 2268 > Washington DC 20375, USA fax: > (1) 202 767 4642 > > NRL Synchrotron Radiation Consortium (NRL-SRC) > Beamlines X11a, X11b, X23b > 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/listi> nfo/ifeffit >

5 4

Re: EXAFS question
by Bruce Ravel 26 Jul '04

26 Jul '04

Norman, Your question is the sort of thing that is appropriate for the Ifeffit mailing list, so I am CCing my answer there. You should consider joining the mailing list. It is a great resource and gives you access to a large number of experts who can answer your questions. On Friday 23 July 2004 03:38 pm, Norman White wrote: NW> In going through Matt Neville's xas_fun_slides.pdf file that was NW> included with the Athena software, I noticed on slide 36: MN > The Fe-O distance in FeO is 2.14 ° A, but the first peak is at 1.6 ° A. MN > This shift in the first peak is due to the phase-shift, MN > delta(k): sin[2kR + delta(k)] . MN > A shift of -0.5 ° A is typical. NW> I asked him in an e-mail about the shift and he said (edited): MN > For traditional XAFS analysis, we do a relatively simple Fourier MN > transform. This simple FT would give a peak in chi(r) at 'R' if MN > the oscillatory part was sin[2kR]. Since it's sin[2kR + delta(k)] MN > instead, there's a shift. MN > MN > It turns out that, to first order, delta(k) is linear and has a MN > negative slope of about 1: MN > delta(k) ~= -k ~= -2k (0.5), MN > MN > so that the shift in phase is about 0.5A. NW> I asked if this was true for all elements and he said: MN > It's a typical value for most bonds, but shouldn't be taken as an MN > accurate number (and it's easy enough to calculate). NW> NW> How is an accurate shift calculated? Is this correction performed This calculation is computed quite accurately by Feff. Indeed, getting that calculation (and the related calculation of the scattering amplitude) correct is the raison d'etre of Feff. NW> automatically in Athena? If it is a constant, why is it not simply NW> included in the step producing the radial distribution function from NW> the k values? Can it be accurately calculated? The manual had NW> statements that seemed to imply that it could be calculated with the NW> Atoms program but did not explain how at a level I understood. NW> NW> Matt neville stated in an e-mail that: MN > The phase shift correction can be made fairly easy with MN > SixPack and with Artemis as well as Ifeffit. It's not a constant and treating it as such would be specious at best, and it is not something that Athena intends to compute. However, since it is something that Feff computes, one can imagine using the results of Feff. How this is done is slightly different in Athena as in Artemis. At the level of Athena, we know the absorbing atom but it is not actually necessary to know what the material is to use Athena effectively. In Artemis, on the other hand, we do have to know something about what the materials is. This difference between the two explains the rationale for how phase correction works i the two programs. In Athena, only a central atom phase correction is supported. This is enabled by clicking the button that says "phase correction" in the forward trasform section of the mail window. With that button clicked, the central atom phase shift is subtracted from the data before the transform is made. When you plot chi(R), then, the transform will be peaked a little bit to the right of where it was peaked without that button clicked. Artemis does a somewhat better job of this. In Artemis, you can select a path to use for pase correction. With a path selected, the central *and* scattering atom phase shifts will be subtracted before transforming. This is possible in Artemis because we have the fuill information about the material and the full feff calculation at our disposal. In Athena, in contrast, we only know about the absorber and I have never implemented (and don't really intend to do so) a way of reading in a feff path for the purpose of phase shifted transforms. NW> NW> I could not find where it explained how to do this. Did you read any of the documentation? For Athena: http://leonardo.phys.washington.edu/~ravel/software/exafs/doc/Athena/athena… The document is also available within Athena via the Help menu. For Artemis: Section 5.8.5 of http://leonardo.phys.washington.edu/~ravel/software/exafs/doc/artemis.pdf NW> I am looking at As adsorption on Fe-Al oxides and other minerals NW> I know what the central atom is As. NW> I can also estimate the oxygen bondlengths and the As-cation distance from NW> the "corrected" EXAFS pattern and the literature. Is it possible to NW> simulate an EXAFs pattern? NW> Is so, how? Yes. Have you read the Artemis manual? B -- Bruce Ravel ----------------------------------- ravel(a)phys.washington.edu Code 6134, Building 3, Room 405 Naval Research Laboratory phone: (1) 202 767 2268 Washington DC 20375, USA fax: (1) 202 767 4642 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b 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: Artemis Question
by Kelly, Shelly D. 26 Jul '04

26 Jul '04

Hi Scott, Feff uses the placement of the atoms to determine the size of the muffin tin radius and the norman radius, which define where the atom is verse where the atom is not. If there are no neighboring atom then these radii become unphysically large and then the scattering amplitudes will not be accurate. -Copper is kinda special. Copper has 12 neighboring atoms, so the muffin tin radii are pretty well constrained even with one shell. If you run a feff calculation with all the Cu atoms in a cluster to 7 Angstroms the top of the feff0001.dat file shows the radii for the atoms and it looks something like this: For large cluster Rmax=7.0 Angstroms: #Copper, Kittel, ISSP Feff 7.02 # metal, fcc # Abs Z=29 Rmt= 1.305 Rnm= 1.454 K shell # Pot 1 Z=29 Rmt= 1.273 Rnm= 1.391 # Gam_ch=1.761E+00 H-L exch # Mu=-5.472E+00 kf=1.724E+00 Vint=-1.679E+01 Rs_int= 2.104 Now do it again for N=12 and Rmax=3.0 For small cluster Rmax=3.0 Angstroms, N=12 # Copper, Kittel, ISSP Feff 7.02 # metal, fcc # Abs Z=29 Rmt= 1.233 Rnm= 1.467 K shell # Pot 1 Z=29 Rmt= 1.282 Rnm= 1.570 # Gam_ch=1.761E+00 H-L exch # Mu=-4.594E+00 kf=1.474E+00 Vint=-1.287E+01 Rs_int= 2.461 And again for N=2 and Rmax =3.0 For small cluster Rmax=3.0 Angstroms, N=2 #Copper, Kittel, ISSP Feff 7.02 # metal, fcc # Abs Z=29 Rmt= 1.256 Rnm= 1.815 K shell # Pot 1 Z=29 Rmt= 1.296 Rnm= 1.872 # Gam_ch=1.761E+00 H-L exch # Mu=-3.892E+00 kf=1.204E+00 Vint=-9.411E+00 Rs_int= 3.013 You can see that the norman radius gets really big for the last case, 1.391 to 1.570 to 1.872 and as a result the scattering amplitude changes. I show a comparison of the chi(k)xk for each of these inputs with a N=1.0, DE=0, SS=0, S02=1.0, DR=0 in the attached clustersize.jpg file. Shelly > -----Original Message----- > From: Scott Calvin [mailto:SCalvin@slc.edu] > Sent: Wednesday, July 21, 2004 9:53 AM > To: XAFS Analysis using Ifeffit > Subject: RE: [Ifeffit] Re: Artemis Question > > > Shelly said: > > > > >Feff is truly amazing. > > Amen! > > >1) Feff needs to have a list of atoms that extends well beyond the > >paths that are actually used in the fit. Always pad the feff.inp > >file by at least an Angstrom. If you are using feff calculation for > >the first time. Pad the feff list by one angstrom and then by two > >angstroms and check that the paths that you are going to use are the > >same. You do not want to use paths from the edges of the cluster > >that you give to feff in the feff.inp file. -Hence you need to use > >a structure like a metal-oxide to model a hydrated metal. > > Under what circumstances does FEFF actually need these extra atoms? > When I take the copper example included by Artemis, for example, I > can rerun the FEFF calculation with a cluster size of 3 angstroms, so > that FEFF only has the nearest-neighbors to deal with. The path > generated is identical to when a cluster size of 7 angstroms. > Certainly if someone is using FEFF8 with a self-consistent field > calculation it is necessary to have the cluster extend beyond the > furthers paths, but with FEFF6L is this true? > > (Incidentally, for the novices out there, I do NOT recommend being > satisfied with a single-shell fit when you have a reasonable guess as > to the structure beyond the first-shell. One reason can be seen > easily with Artemis: paths beyond the first-shell often have low-R > "tails" that contribute to the signal even at the first-shell peak. > Although the FEFF calculation for the first path may be the same > whether or not you also calculated paths further out, the Ifeffit fit > will be different depending on whether you include those "outer" > paths or not.) > > --Scott Calvin > Sarah Lawrence College > > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listi> nfo/ifeffit >

6 6

RE: [Ifeffit] weights data processing
by Kelly, Shelly D. 23 Jul '04

23 Jul '04

> -----Original Message----- > From: Stefano Ciurli [mailto:stefano.ciurli@unibo.it] > Sent: Friday, July 23, 2004 6:31 AM > To: ravel(a)phys.washington.edu; XAFS Analysis using Ifeffit > Subject: [Ifeffit] weights data processing > > > Hi folks, > > 1) when removing background using athena, there is an option of using > a k-weight different than 1 (I am NOT talking about k-weight for FT). > I noticed that changing this parameter the resulting chi(k) does not > change significantly. Actually, going from 1 to 4 as a value for > k-weight for Bkgd removal, the only effect I see is a significant > reduction of the peak below the first coordination shell in chi(R) > while the other features of the spectrum are essentially the same in > terms of absolute and relative intensity. A drastic change in both > chi(k) and chi(R) is seen if I use k-weight = 5 and above. What is > the exact meaning of it? I know what the meaning is in the FT > process, but I do not see the reason why I should use a weight > different than 1 (let's say 3 for my noisy data) for background > removal. How should I behave? Should I take the largest value of > k-weight so that the essential features of the chi(k) and chi(R) do > not change? Hi Stefano, I have found a procedure for removing the background that "almost" always works well. It goes something like this and uses different k-weightings in the background removal process. 1) Check out the curvature of the XANES region and how quickly the data goes from zero to 1, call this DExanes. There are in my small opinion two categories for each of these different parameters. Curvature of Xanes can be step like or it can have a large peak. DExanes can be small ~10eV for k-edges of Cu or wide ~30eV for L3-edge of U. 2) Choosing Ezero for the first time: If you have a wide DExanes, then choose Ezero up near the top of the edge. If you have a small DExanes, then choose Ezero around the middle of the edge. 3)Set kweight equal to one or zero (and no theory) and remove the background. This will emphasize the low k-region around the edge, but often get the background for the higher k-region not as well...especially for noisy data. 4)Check out the shape of the background function, the chi(k) data and the FT. Make sure that rbkg=1.0 is a reasonable thing to do. Make sure that you look at the chik data with all three k-weights. Often people say that there is no change in the chik data by changing the kwieght but they are looking at the chik*k3. The change will be greatest at low k, which you don't really see with chik*k3. 5) If you have a large peak in the XANES region, Athena may need help getting the bkg to go through that peak. You have two options. A) increase rbkg so that the spline has more freedom to curve in this region. or B) increase kmin of the spline range, essentially removing the large peak from the data. 6) Fit the first shell of your data, use a well padded chik data range...don't include at least one full oscillation at the beginning. i.e. use kmin=3 or greater. Monitor the value for ezero. If it is greater than 10eV you need to start over. (I have some more details on how to create a theory to be used for bkg removal on my web site http://www.mesg.anl.gov/Skelly.html from the 2004 NSLS EXAFS workshop presentation) 7) Read the theory back into Athena. Now Athena knows what the low k-range should look like, and you can increase the k-weight of the background, use kw=2 or 3, to get the high k-range part of the data correct as well. 8) Fit the data again and use as much of the k-range as possible. > > 2) In artemis, is it a bug or a wanted feature to have the > possibility to activate more than one button for k-weight for the fit > and FT? I suppose it is a wanted feature, but then I wonder what is > the meaning of using more than one weight for the fit and FT. I am > sure some of you can unveil this enigma. > Another couple of reasons to use more than 1 k-weight in the FT of the data: I have found that the uncertainties in the fitted values are about half as big by using all three k-weights, as opposed to using just one k=weight. I have also found that using all three k-weights will force you to model the data much more correctly. When you look at the fits, you need to look at the FT and the chi(k) data using all three k-weights. HTH Shelly

1 0

Re: [Ifeffit] Solution flow cells
by Scott Calvin 23 Jul '04

23 Jul '04

Thanks to all for the references, advice, etc.! This list really works wonders sometimes... --Scott Calvin Sarah Lawrence College

1 0

using atoms and feff
by Barton, David (DG) 23 Jul '04

23 Jul '04

I agree with Scott, the ICSD database of crystallographic structures has also been invaluable to my work on inorganic solids. However, the ICSD is truly an inorganic database in that it does not contain any compounds that contain carbon. For small molecule crystalline compounds that contain carbon the Cambridge Structural Database (http://www.ccdc.cam.ac.uk/ <http://www.ccdc.cam.ac.uk/> ) is quite useful. It contains ~300,000 crystal structures of organic and organometallic compounds. However, this database comes with a significant price tag, but if you can get access it is an amazing tool. Both of these crystallographic databases will write out the records in the CIF (Crystallographic Information File) format. I have written a command line Perl program which converts these CIF records to Atoms.inp files which can be used directly with Artemis. Shelly Kelly was kind enough to host the files: http://146.137.194.45/exafs.html <http://146.137.194.45/exafs.html> . Eventually, we may see a CIF import feature based on this code included in Artemis. Another Crystallographic File converter that I have found useful is CRYSCON (ShapeSoftware: http://www.shapesoftware.com/ <http://www.shapesoftware.com/> ). This shareware program will interconvert nearly all crystallographic file formats and, at my request, the author recently added support to export files with Ravel's ATOMS file format. Dave Barton The Dow Chemical Company, DND-CAT member at APS

1 0