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

Debye-Waller factors for metal oxides ?
by Ian James Drake 16 Apr '09

16 Apr '09

Hi, There is little discussion over the significance of fitted Debye-Waller factors (ss2) found for metal centers in metal oxides of heterogeneous catalysts. I am searching for a better way of determining how reasonable these values are in the fits I get. 1. Are phenomenological models like the correlated Debye model and Einstein model appropriate? It seems that Debye temperatures are hard to find for oxides. 2. Is there an equivalent value for ss2 in x-ray crystallography data that I can refer to for comparison in these materials? What should I look for in reviewing published x-ray crystallographic data? 3. Is the temperature dependence reported for the ss2 for some metals (like Cu and Al) similar to their respective oxides? For example, in Debye-Waller factor calculations reported for Al metal by R.C.G Killean (in J.Phys.F: Metal Phys., v. 4, pg. 1908, 1974), the ss2 changes by a factor of three between 25C and 300C. Would I expect a factor of three increase in crystalline zeolites (AlO4 structural units). 4. Specific to my work: I have studied Al containing oxides at temperatures between 25 and 300 C. I would like to quantify coordination changes by doing EXAFS fitting of the Al K-edge data. The EXAFS was taken at temperature and I observe no change in the broadening of the data. Likewise, the fitting shows no sensitivity in the Debye-Waller factor. It is nearly constant at 0.001 A over the temperatures of interest. Since ss2 and the coordination number (CN) are correlated, I would like a way to bind the error on the fitted CN by modeling real physical changes in the Debye-Waller factors. Do you have any suggestions? Looking forward to your thoughts. Ian Drake Graduate Student UC Berkeley

9 21

New Method for Normalization?
by Barton, David (DG) 30 Mar '09

30 Mar '09

XANES Aficionados, I know most users on this list are hard-core EXAFS analysts, but some of us use XANES analysis to decipher mixed phases or use it to get structural clues when data quality isn't sufficient for EXAFS analysis. Anyway, I have a question for those interested in quantitative analysis of XANES or those that are willing to offer an opinion on methods to normalize raw spectra to get reliable, repeatable comparisons of near-edge features. Has anyone considered using the methods of Penner-Hahn to normalize their data to get reliable intensities of near-edge features? The reference to their method of normalization is below: J. Synchrotron Rad. (2005). 12, 506-510 [doi:10.1107/S0909049504034193] "A method for normalization of X-ray absorption spectra" T.-C. Weng, G. S. Waldo and J. E. Penner-Hahn It is my understanding the Ifeffit uses a linear function to remove the pre-edge and a quadratic for the post-edge and that the Athena's flatten is a subtraction of these functions. This is an excellent method under most scenarios since the background is usually fairly smooth and can be well approximated by a quadratic equation. Personally, I have had only a few rare cases where the quadratic function on the post-edge was not sufficient to reliably normalize the data and in those cases a third-order polynomial was sufficient. Does anyone else have an opinion on using alternative normalization routines? Dave _________________________________ David Barton The Dow Chemical Company

12 22

Re: [Ifeffit] OS X: (was: new release (061) of my codes)
by Matt Newville 28 Nov '06

28 Nov '06

Bruce, everyone Mac-interested: I believe many of the problems that have been seen come from the idea that one can install the binary, and then expect upgrading from source to work. I believe this will always be fragile: Mac OS X does not come with an installed compiler for C or Fortran (they are available). For these machines, the standard 'perl Makefile.PL' will fail. Whether this is the cause of the recent problems is a separate question. The way I see it, there are two ways to go here: A) assume that Mac is "just-another-version-of-Unix" so that installations and upgrading from source should work. B) assume that Mac is as special as Windows, and that ALL installations and upgrades need an actual installer or a simple, foolproof upgrade mechanism that involves no users typing at a terminal. An "upgrade" could simply consist of a zip file of new files, but we'd need a program (like exists for Windows) that did this upgrading semi-automatically. If the perl upgrades were "pure perl" and did not include a compilation, it could probably be made to work more reliably. But I don't quite see that as the right solution, because it still expects upgrades to happen with a different model than the original installation. Personally, I'm not thrilled about having to support option A. Option B means that someone will have to do the work of making and testing binary installers and upgrades. It will probably mean having to stick close to Mac OS X upgrade cycle. But I think we need a consensus on this. Any opinions? --Matt

5 11

silly me!
by Bruce Ravel 06 Sep '06

06 Sep '06

Hi folks, It just occured to me that I didn't mention the web page where I document all the changes to my codes in the most recent release. Athena especially has a number of interesting new features. You might want to take a look at this http://cars9.uchicago.edu/iffwiki/HoraeVersion062 B -- Bruce Ravel ---------------------------------------------- bravel(a)anl.gov Molecular Environmental Science Group, Building 203, Room E-165 MRCAT, Sector 10, Advanced Photon Source, Building 433, Room B007 Argonne National Laboratory phone and voice mail: (1) 630 252 5033 Argonne IL 60439, USA fax: (1) 630 252 9793 My homepage: http://cars9.uchicago.edu/~ravel EXAFS software: http://cars9.uchicago.edu/~ravel/software/exafs/

2 1

Re: Ifeffit Digest, Vol 40, Issue 10
by Michel Jaouen 07 Aug '06

07 Aug '06

>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-owner(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. data file format (emmanuelle montarges-pelletier) > 2. Re: data file format (Matthew) > 3. Re: data file format (Bruce Ravel) > 4. The most important fitting parameters (Bridget Ingham) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Wed, 21 Jun 2006 10:25:47 +0200 >From: emmanuelle montarges-pelletier > <emmanuelle.montarges(a)ensg.inpl-nancy.fr> >Subject: [Ifeffit] data file format >To: ifeffit(a)millenia.cars.aps.anl.gov >Message-ID: <1F268809-6D80-4EE8-996D-209DFF3FEE07(a)ensg.inpl-nancy.fr> >Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed > >Hello >I have some problems with data file format as I try to import exafs >files in Artemis or in Athena. >I am working on a powerbook G4, with OSX 10.4.6. I installed the >ifeffit package, including Athena and Artemis. Athena could open any >XAS "raw" file from fluorescence or transmission measurements. >However, if I perform any modifications on these raw files with >exterior programs (Michalowicz programs, Kaleidagraph) and try to >import the new files , saved as text files, Athena or Arthemis can >not open them. I guess it may come from the encoding of the text >file. Do you have any clue on this encoding issue? Do you know any >program which would allow me to transform these text files in >readable files for Artemis? >Thank you for your answer >sincerely >Emmanuelle > > >There are two types of encodings which may differ among text files from >different countries and OSs. I >don't know how Athena&Co. handle either of them. One is that numbers and >decimals can differ per country. If >Kgraph is using a local encoding other than the American standard, say, >using commas instead of periods, it's possible >that Artemis won't understand it. I have the same problem with my analysis >programs. Every so often I get a panicky email >from a user whose files won't open. The other variation is in what >constitutes the end of a line, which is OS-dependent. It could >be carriage return, linefeed, or CR-LF. > mam > > >Salut Emmanuelle, > >Matthew's suggestion of floats with commas is a good suggestion. A&A >make no attempt at respecting localization. (That is, a number >between one and two might be written as 1,234 -- which would confuse >A&A -- rather than 1.234.) If that is the case, your best bet is to >go back to the exterior program and ask it nicely to write out points >instead of commas. Or you might need to edit the file by hand. > >I thought that the end-of-line issue (Matthew's other suggestion) was >one that was solved in A&A years ago. If that proves not to be the >case, please let me know. > >Another possibility is that the exterior program added other text to >the file that is confusing A&A. Here is my explanation of how Athena >reads ascii data files > > http://cars9.uchicago.edu/iffwiki/FAQ/HoraeQuestions > >and here is the explanation of the file-reading function in Ifeffit >which Athena uses: > > http://cars9.uchicago.edu/~ifeffit/refman/node24.html > >The situation in Artemis is similar, although restricted in the sense >that Artemis is expecting its data to be chi(k). > >If none of that clarifies the issue for you, I'll need to see an >example of the data file which is causing the problem. > >The easiest way to move data from Athena to Artemis is to have Artemis >import its data directly from the Athena project file. > >If there is some data processing feature that Athena does not do but >which you require before moving on to data analysis, you should >consider making a feature request here on the mailing list. Athena >will never get the features that you need if I am not aware that they >are needed! > >B > Just an additional point: take care to save the file as unix file and not standard Mac (use a free text editor as TextWrangler to do this kind of manipulation). Michel -- __________________________________________ Michel Jaouen Universite de Poitiers - UFR Sciences - SP2MI LMP UMR 6630-CNRS Boulevard Pierre et Marie Curie - Teleport 2 BP 30179 86962 Futuroscope - Chasseneuil Cedex France Tel : (33) 5 49 49 67 37 Fax : (33) 5 49 49 66 92 e-mail : Michel.Jaouen(a)univ-poitiers.fr __________________________________________

4 3

E0 and background subtraction
by Vadim G Palshin 29 Jun '06

29 Jun '06

Hi everyone, I have the following question: I have a set of spectra collected in transmission with 3 ionization chambers and a standard between 2nd and 3rd ion chambers for calibration, so I know my spectra are nicely calibrated relative to each other. Should I then force Athena(/autobk) to use the same E0 for all of them (e.g. use the atomic value) or let it find E0 independently for each sample? Thanks! Vadim.

4 3

Fwd: Re: r-factor
by Bruce Ravel 23 Jun '06

23 Jun '06

On Friday 23 June 2006 05:01, you wrote: > I have a question about Artemis log file. I noticed that two r-factors are > reported in the log file. One is in the fifth line and it is called > 'R-factor' and the other one is under the data set fitting conditions and > it is called 'r-factor for this data set'. They have in general different > values. What does it mean? Which is the difference between the two? It probably means that I am calculating something wrongly. Here's the concept. If you do a multiple data set fit and you have some value of R-factor, you would like to know how that misfit is partitioned among the data sets. That is, you'd like to know if one set is contributing to the misfit for significantly than the others. When Ifeffit computes the R-factor, it is for the entire fit. My idea in Artemis was to use the formula for R factor from page 18 of http://cars9.uchicago.edu/~newville/feffit/feffit.ps on each data set in a multiple data set fit and report that in the log file. At some point, I must have convinced myself that I was doing the calulcation in Artemis identically to how it is done in Ifeffit. If you are seeing different values, it would seem I was mistaken. I'll make an entry in my to do list to look into that. B -- Bruce Ravel ---------------------------------------------- bravel(a)anl.gov Molecular Environmental Science Group, Building 203, Room E-165 MRCAT, Sector 10, Advanced Photon Source, Building 433, Room B007 Argonne National Laboratory phone and voice mail: (1) 630 252 5033 Argonne IL 60439, USA fax: (1) 630 252 9793 My homepage: http://cars9.uchicago.edu/~ravel EXAFS software: http://cars9.uchicago.edu/~ravel/software/exafs/

1 0

data file format
by emmanuelle montarges-pelletier 22 Jun '06

22 Jun '06

Hello I have some problems with data file format as I try to import exafs files in Artemis or in Athena. I am working on a powerbook G4, with OSX 10.4.6. I installed the ifeffit package, including Athena and Artemis. Athena could open any XAS "raw" file from fluorescence or transmission measurements. However, if I perform any modifications on these raw files with exterior programs (Michalowicz programs, Kaleidagraph) and try to import the new files , saved as text files, Athena or Arthemis can not open them. I guess it may come from the encoding of the text file. Do you have any clue on this encoding issue? Do you know any program which would allow me to transform these text files in readable files for Artemis? Thank you for your answer sincerely Emmanuelle ********************************************* Emmanuelle Montargés-Pelletier CR CNRS LEM UMR7569 CNRS-INPL-ENSG 15 avenue du charmois BP40 54501 Vandoeuvre les Nancy cedex France Tel 33 (0)3 83 59 62 52 fax 33 (0)3 83 59 62 55 emmanuelle.montarges(a)ensg.inpl-nancy.fr http://www.ensg.inpl-nancy.fr/lem/ **************************************************

4 8

The most important fitting parameters
by Bridget Ingham 21 Jun '06

21 Jun '06

Hi Bruce and Shelly, thanks for your replies. The problem I am encountering is that we know virtually nothing about the crystallography, only the elements that are present. We expect the structure to be quite different to CuWO4, even though this is the stoichiometry obtained. Addressing some of your questions/comments: Shelly: 1) I will try this. In other systems I've tried the second oxygen shells don't contribute significantly, so maybe they are unnecessary and only adding to the uncertainty in the other shells. 2) & 3) As mentioned above, we don't even know this about the structure. But it is worth me having a go at restricting the delr's to relate to CuWO4. I am loathe to do the same with the amplitudes however, as I expect the co-ordination numbers to be completely different. 4) Yes, I ran a CuWO4 standard at the same time. It looks completely different ;) 5) & 6) Thanks for these tips! Bruce: I have kept E0 the same for all shells, hence 13 parameters (4 shells x amp, delr, ss; plus E0). Sorry for not making that clear enough. The data stops at 9 Ang-1 because there seems to be some Zn edge impurity :( I will play around with the constraints a bit more (starting with the CuWO4 standard) and let you know how I get on. Thanks again for your help! Bridget This electronic transmission and any documents accompanying this electronic transmission contain confidential information belonging to the sender. This information may be legally privileged. The information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on or regarding the contents of this electronically transmitted information is strictly prohibited. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

Debian packages of ifeffit and horae
by Carlo Segre 20 Jun '06

20 Jun '06

It has taken a bit of time but the Debian packages of ifeffit and horae are now uploaded to my apt repository. Note that horae requires a new Perl module to be installed (libtext-glob-per) and so will have to be upgraded expplicitly. Also note that if you are using the "etch" or "sid" versions of the packages, that a new version of pgplot5 will be also installed. This is to correct a serious bug that exists in the Debian version at this time. Thanks to Ken McIvor for fixing this. hopefully a new official Debian version will be coming out soon to fix this officially. The repositories for the various distributions are, as always: # For the stable (sarge) distribution deb http://fermi.phys.iit.edu/debian/sarge binary/ deb-src http://fermi.phys.iit.edu/debian/sarge source/ # For the testing (etch) distribution deb http://fermi.phys.iit.edu/debian/etch binary/ deb-src http://fermi.phys.iit.edu/debian/etch source/ # For the unstable (sid) distribution deb http://fermi.phys.iit.edu/debian/sid binary/ deb-src http://fermi.phys.iit.edu/debian/sid source/ 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