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

Re: [Ifeffit] Launching Athena on Mountain Lion (Mac OS 10.8)
by Kyler Carroll 04 Dec '14

04 Dec '14

Hello, I had posted a comment/question a few months back when I had initially installed Mountain Lion on my mac regarding iXAFS compatibility with XQuartz and the new OS not supporting X11 anymore. Since then I have received a few comments back and I found one solution to be the best. This was originally sent by Tsu-Chien Weng from SSRL (tsuchien(a)slac.stanford.edu) Please find the following solution below. Once you install XQuartz the rest will be done in the Terminal.app. This is a one time solution and I havent had any trouble thus far with the program. Hope this works as well for everyone else as it did for me. 1. Install XQuartz from <http://xquartz.macosforge.org/landing/> 2. open Terminal.app 3. cd /Applications/Utilities 4. sudo mkdir X11.app 5. cd X11.app 6. sudo ln -s ../XQuartz.app/Contents Thank you, Kyler J. Carroll, Ph.D. Assistant Project Scientist Department of NanoEngineering University of California, San Diego

3 2

Possible bug - dathena does not work on XP mode
by ASAKURA, Hiroyuki 01 Jun '13

01 Jun '13

Dear list, I am trying to use dathena, dartemis and dhephaestus in Demeter 0.9.17 package on Windows XP ("XP mode" on Windows 7), but neither Athena nor Artemis nor Hephaestus works. On Windows 7 (both 32 bit and 64 bit), everything works. The symptoms are similar to the latest post's, the command prompt and the splash screen appears momentarily, disappears, and then nothing happens. In contrast, (stand-alone) Atoms opens. Reinstallation of Demeter does not solve this booting problem. I checked MinGW and demeter.mru problems reported on this ML, but there are no other MinGW installation or corrupted detemer.mru. OS: Windows XP on Virtual PC ("XP mode" on Windows 7 32 bit) (Japanese version) (All updates are applied.) Demeter: 0.9.17 (on standard path C:\strawberry...) (ver. 0.9.13.1 also does not work.) In addition, I've heard that this phenomenon happens at least on Windows XP in many other real machines. (not on virtual machines) Any suggestions would be appreciated. Best regards, ASAKURA, Hiroyuki -- ASAKURA, Hiroyuki Designated Research Associate Synchrotron Radiation Research Center, Nagoya University, Japan h.asakura(a)nusr.nagoya-u.ac.jp

2 3

Bug Report - (D)Athena Doesn't Open
by Rodriguez, Roberto 29 May '13

29 May '13

I'm currently having trouble opening both (D)Athena and (D)Artemis. When I first installed Demeter a couple months ago, the programs worked properly without any issue until recently. In both cases, the command prompt and the splash screen appear momentarily, disappears, and then nothing happens - the program never opens. To my knowledge, no settings have been changed that would prevent Athena/Artemis from opening. In contrast, (D)Hephaestus and (D)Atoms open and appear to function properly. I've tried uninstalling/reinstalling Demeter 0.9.13.1 in addition to installing the Updater 0.9.17, but I keep having the same issue. Any suggestions would be most helpful. Operating system is Windows 7 Enterprise. Regards, Roberto Roberto Rodriguez Development Engineer UOP LLC, A Honeywell Company 25 E Algonquin Rd., Des Plaines, IL 60017 Office: Bldg. 2, 350-B Office Phone: (847)391-2582 Cell: (815) 351-4481 Email: Roberto.Rodriguez(a)uop.com<mailto:Roberto.Rodriguez@uop.com>

3 2

closing Artemis project
by Christopher Patridge 28 May '13

28 May '13

Hello, I have a question about (D)Artemis. After saving a project, I used the Close option under File. This does remove the datasets and feff calculations but it keeps the name of the project in main window header. Is there a way to begin a new project other than closing Artemis and/or beginning a project and use the save as option? One other thing, is there any possibility of extending the number of datasets for artemis? Thanks, Chris Patridge -- ******************************** Christopher J. Patridge, PhD NRC Post Doctoral Research Associate Naval Research Laboratory Washington, DC 20375 Cell: 315-529-0501

2 1

Demeter 0.9.17
by Bruce Ravel 28 May '13

28 May '13

Hi, I just uploaded a new Windows updater package for Demeter and tagged version 0.9.17 at GitHub. This release introduces no new features but fixes the handful of problems reported in recent weeks. The updater package can be obtained at Demeter's homepage: http://bruceravel.github.io/demeter/ Cheers, B -- Bruce Ravel ------------------------------------ bravel(a)bnl.gov National Institute of Standards and Technology Synchrotron Methods Group at NSLS --- Beamlines U7A, X24A, X23A2 Building 535A Upton NY, 11973 Homepage: http://xafs.org/BruceRavel Software: https://github.com/bruceravel

1 0

Opening XANES Files with Athena
by Alex Kellum 24 May '13

24 May '13

Hello All, I am working on an NSF-REU program this summer requiring me to analyze XANES spectra. My personal computer is a mac (w/ OS X 10.6.8). I am desperately trying to figure out how to even open an IFEFFIT program that will help me analyze the spectra. The spectra are saved in .txt files--and I have no idea how to convert them to .apj or .prj files. Is it possible to analyze them with converting them? Right now I am using iXAFS Shell containing Athena, Artemis and Hephaestus. I realize there are newer versions available, but Demeter is only available on Windows and I spent a few hours trying to get Larch to work. Even after downloading python I had no idea how to get it to actually download and work. I do have X11 running on my computer. I realize you probably get a ton of emails from users, but any help would be greatly appreciated. Regards, Alex Kellum

3 2

Correction to radial distance
by Francisco Garcia 24 May '13

24 May '13

Dear all, Can an experienced user kindly explain how to obtain the phase shift correction to the radial distance corresponding to FFT(chi(k)). From my chi(k) computation, I have several feff*.dat files (feff0001.dat, feff0002.dat,...............,feff00128.dat) because I have 128 paths. How do I use this information and IFEFFIT to compute the shifted spectrum? Thank you.

2 1

JFEFF/FEFF9 "Save&Run" no longer works after Java Update -- FEFFgroup announcement
by Kevin Jorissen 16 May '13

16 May '13

Dear iFEFFIT community, a short update from the FEFF developers team: A recent Java update (Java 7 Update 21) broke some functionality of the JFEFF interface for the FEFF program. Users who update to J7U21 have noticed that when they click "Save&Run" nothing happens: the FEFF programs do not run and there is no output. We think this issue will affect people on all Operating Systems. To fix this issue there are two possibilities: * Roll back Java to a previous version. For security reasons please have at least Java 7 Update 11, which was an important security update, or newer. Instructions for rolling back Java can be found online. * We have updated JFEFF to work with the latest Java. This latest (J)FEFF version is not yet available on the official download website, but FEFF users with a valid license can contact us and we will provide them with a download link for the latest (J)FEFF. Please contact us directly. Users who currently have FEFF8 can upgrade to FEFF9 at any time at a discounted rate. Thank you to Linda Lim for her earlier post on the iFEFFIT ML. Cheers, Kevin Jorissen FEFFgroup - University of Washington

1 0

normalization methods
by Matt Newville 16 May '13

16 May '13

Hi Folks, Over on the github pages for larch, Mauro and Bruce raised an issue about the "flattening" in Athena. See https://github.com/xraypy/xraylarch/issues/44 I've added a "flattened output" from Larch's pre_edge() function, but the question has been raised of whether this is "better" than the simpler normalized spectra, especially for doing PCA and/or LCF for XANES. Currently, the "normalized" spectra is just "(mu - pre_edge_line)/edge_step". Clearly, a line fitted to the pre-edge of the spectra is not sufficient to remove all instrumental backgrounds. In some sense, flattening attempts to do a better job, fitting the post-edge spectra to a quadratic function. As Mauro, Bruce, and Carmelo have pointed out, it is less clear that it is actually better for XANES analysis. I think the main concerns are that a) it is so spectra-specific, and b) it turns on at E0 with a step function. Bruce suggested doing something more like MBACK or Ifeffit's bkg_cl(). It would certainly be possible to do some sort of "flattening" so that mu follows the expected energy dependence from tabularized mu(E). Does anyone else have suggestions, opinions, etc? Feel free to give them here or at the github page.... --Matt

3 12

Re: [Ifeffit] normalization methods
by Zack Gainsforth 15 May '13

15 May '13

Hi All, We did an analysis comparing on order of 100 XANES spectra and found that a normalization producing the most stereotypically "correct" spectrum did not always produce the best linear combinations between them. That is, we tend to think a XANES spectrum should be flat (derivative=0) before the edge, and then there is a step, and wiggles, and the wiggles are centered around another flat line. Certainly, this form of spectrum communicates well in publications, and probably it is best for publications given that different researchers use different normalization algorithms. However, when comparing XANES spectra against each other quantitatively, it is more important that the subtraction method be the same. What we did that worked well was write a normalization routine in MATLAB (derived from Matthew Marcus' description since we acquired XANES on his beamline). Then we were better able to compare spectra and fit them against each other using linear combination. When using spectra that were individually normalized, the linear combinations were never as good. Incidentally, this is an argument for always including raw spectra in supplementary materials even though you would want to use the normalized spectrum in a publication. Cheers, Zack On May 15, 2013, at 9:58 AM, ifeffit-request(a)millenia.cars.aps.anl.gov wrote: 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. normalization methods (Matt Newville) 2. Re: normalization methods (Matthew Marcus) 3. Re: normalization methods (Matt Newville) 4. Re: normalization methods (Matthew Marcus) 5. Re: normalization methods (George Sterbinsky) ---------------------------------------------------------------------- Message: 1 Date: Wed, 15 May 2013 09:35:41 -0500 From: Matt Newville <newville(a)cars.uchicago.edu> To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> Subject: [Ifeffit] normalization methods Message-ID: <CA+7ESboBg5uOS6or-TurJy9zPGhoA73c+bErNkWsuO4GC4Cpug(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi Folks, Over on the github pages for larch, Mauro and Bruce raised an issue about the "flattening" in Athena. See https://github.com/xraypy/xraylarch/issues/44 I've added a "flattened output" from Larch's pre_edge() function, but the question has been raised of whether this is "better" than the simpler normalized spectra, especially for doing PCA and/or LCF for XANES. Currently, the "normalized" spectra is just "(mu - pre_edge_line)/edge_step". Clearly, a line fitted to the pre-edge of the spectra is not sufficient to remove all instrumental backgrounds. In some sense, flattening attempts to do a better job, fitting the post-edge spectra to a quadratic function. As Mauro, Bruce, and Carmelo have pointed out, it is less clear that it is actually better for XANES analysis. I think the main concerns are that a) it is so spectra-specific, and b) it turns on at E0 with a step function. Bruce suggested doing something more like MBACK or Ifeffit's bkg_cl(). It would certainly be possible to do some sort of "flattening" so that mu follows the expected energy dependence from tabularized mu(E). Does anyone else have suggestions, opinions, etc? Feel free to give them here or at the github page.... --Matt ------------------------------ Message: 2 Date: Wed, 15 May 2013 07:57:14 -0700 From: Matthew Marcus <mamarcus(a)lbl.gov> To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> Subject: Re: [Ifeffit] normalization methods Message-ID: <5193A24A.5090506(a)lbl.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed What I typically do for XANES is divide mu-mu_pre_edge_line by a linear function which goes through the post-edge oscillations. This division goes over the whole data range, including pre-edge. If the data has obvious curvature in the post-edge, I'll use a higher-order polynomial. For transmission data, what sometimes linearizes the background is to change the abscissa to 1/E^2.7 (the rule-of-thumb absorption shape) and change it back afterward. All this is, of course, highly subjective and one of the reasons for taking extended XANES data (300eV, for instance). For short-range XANES, there isn't enough info to do more than divide by a constant. Once this is done, my LCF programs allow a slope adjustment as a free parameter, thus muNorm(E) = (1+a*(E-E0))*Sum_on_ref{x[ref]*muNorm[ref](E)}. A sign that this degree of freedom may be being abused is if the sum of the x[ref] is far from 1 or if a*(Emax-E0) is large. Don't get me started on overabsorption :-) mam On 5/15/2013 7:35 AM, Matt Newville wrote: > Hi Folks, > > Over on the github pages for larch, Mauro and Bruce raised an issue > about the "flattening" in Athena. See > https://github.com/xraypy/xraylarch/issues/44 > > I've added a "flattened output" from Larch's pre_edge() function, but > the question has been raised of whether this is "better" than the > simpler normalized spectra, especially for doing PCA and/or LCF for > XANES. > > Currently, the "normalized" spectra is just "(mu - > pre_edge_line)/edge_step". Clearly, a line fitted to the pre-edge of > the spectra is not sufficient to remove all instrumental backgrounds. > In some sense, flattening attempts to do a better job, fitting the > post-edge spectra to a quadratic function. As Mauro, Bruce, and > Carmelo have pointed out, it is less clear that it is actually better > for XANES analysis. I think the main concerns are that a) it is so > spectra-specific, and b) it turns on at E0 with a step function. > > Bruce suggested doing something more like MBACK or Ifeffit's bkg_cl(). > It would certainly be possible to do some sort of "flattening" so > that mu follows the expected energy dependence from tabularized mu(E). > > Does anyone else have suggestions, opinions, etc? Feel free to give > them here or at the github page.... > > --Matt > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > ------------------------------ Message: 3 Date: Wed, 15 May 2013 10:25:23 -0500 From: Matt Newville <newville(a)cars.uchicago.edu> To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> Subject: Re: [Ifeffit] normalization methods Message-ID: <CA+7ESbrhv1WHj8r2v1-U7wurQCvZnmFjrmAf9HNbTfcRjFn77Q(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi Matthew, On Wed, May 15, 2013 at 9:57 AM, Matthew Marcus <mamarcus(a)lbl.gov> wrote: > What I typically do for XANES is divide mu-mu_pre_edge_line by a linear > function which goes through the post-edge oscillations. > This division goes over the whole data range, including pre-edge. If the > data has obvious curvature in the post-edge, I'll use a higher-order > polynomial. For transmission data, what sometimes linearizes the background > is to change the abscissa to 1/E^2.7 (the rule-of-thumb absorption > shape) and change it back afterward. All this is, of course, highly > subjective and one of the reasons for taking extended XANES data (300eV, > for instance). For short-range XANES, there isn't enough info to do more > than divide by a constant. Once this is done, my LCF programs allow > a slope adjustment as a free parameter, thus muNorm(E) = > (1+a*(E-E0))*Sum_on_ref{x[ref]*muNorm[ref](E)}. A sign that this degree of > freedom > may be being abused is if the sum of the x[ref] is far from 1 or if > a*(Emax-E0) is large. Don't get me started on overabsorption :-) > mam Thanks -- I should have said that pre_edge() can now do a victoreen-ish fit, regressing a line to mu*E^nvict (nvict can be any real value). Still, it seems that the current flattening is somewhere between "better" and "worse", which is unsettling... Applying the "flattening" polynomial to the pre-edge range definitely seems to give poor results, but maybe some energy-dependent compromise is possible. And, of course, over-absorption is next on the list! --Matt ------------------------------ Message: 4 Date: Wed, 15 May 2013 08:41:55 -0700 From: Matthew Marcus <mamarcus(a)lbl.gov> To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> Subject: Re: [Ifeffit] normalization methods Message-ID: <5193ACC3.3090007(a)lbl.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed The way I commonly do pre-edge is to fit with some form plus a power-law singularity representing the initial rise of the edge, then subtract out that "some form". Now, that form can be either linear, linear+E^(-2.7) (for transmission), or linear+ another power-law singularity centered at the center passband energy of the fluorescence detector. That latter is for fluorescence data which is affected by the tail of the elastic/Compton peak from the incident energy. Whichever form is taken gets subtraccted from the whole data range, resulting in data which is pre-edge-subtracted but not yet post-edge normalized. The path then splits; for EXAFS, the usual conversion to k-space, spline fitting in the post-edge, subtraction and division is done, all interactively. Tensioned spline is also available due to request of a prominent user. For XANES, the post-edge is fit as previously described. Thus, there's no distinction made between data above and below E0 in XANES, whereas there is such a distinction in EXAFS. mam On 5/15/2013 8:25 AM, Matt Newville wrote: > Hi Matthew, > > On Wed, May 15, 2013 at 9:57 AM, Matthew Marcus <mamarcus(a)lbl.gov> wrote: >> What I typically do for XANES is divide mu-mu_pre_edge_line by a linear >> function which goes through the post-edge oscillations. >> This division goes over the whole data range, including pre-edge. If the >> data has obvious curvature in the post-edge, I'll use a higher-order >> polynomial. For transmission data, what sometimes linearizes the background >> is to change the abscissa to 1/E^2.7 (the rule-of-thumb absorption >> shape) and change it back afterward. All this is, of course, highly >> subjective and one of the reasons for taking extended XANES data (300eV, >> for instance). For short-range XANES, there isn't enough info to do more >> than divide by a constant. Once this is done, my LCF programs allow >> a slope adjustment as a free parameter, thus muNorm(E) = >> (1+a*(E-E0))*Sum_on_ref{x[ref]*muNorm[ref](E)}. A sign that this degree of >> freedom >> may be being abused is if the sum of the x[ref] is far from 1 or if >> a*(Emax-E0) is large. Don't get me started on overabsorption :-) >> mam > > Thanks -- I should have said that pre_edge() can now do a > victoreen-ish fit, regressing a line to mu*E^nvict (nvict can be any > real value). > > Still, it seems that the current flattening is somewhere between > "better" and "worse", which is unsettling... Applying the > "flattening" polynomial to the pre-edge range definitely seems to give > poor results, but maybe some energy-dependent compromise is possible. > > And, of course, over-absorption is next on the list! > > --Matt > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > ------------------------------ Message: 5 Date: Wed, 15 May 2013 12:58:53 -0400 From: George Sterbinsky <GeorgeSterbinsky(a)u.northwestern.edu> To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> Subject: Re: [Ifeffit] normalization methods Message-ID: <CALoY8YzRCAa3w=8hC=Pn50cysiaVzYR6GrRCZDnW9d2gvPg7Gw(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" The question of whether it is appropriate to use flattened data for quantitative analysis is something I've been thinking about a lot recently. In my specific case, I am analyzing XMCD data at the Co L-edge. To obtain the XMCD, I measure XAS with total electron yield detection using a ~70% left or right circularly polarized beam and flip the magnetic field on the sample at every data point. The goal then, is to subtract the XAS measured in a positive field (p-XAS) from XAS measured in a negative field (n-XAS) and get something (the XMCD) that is zero in the pre-edge and post-edge regions. I often find that after removal of a linear pre-edge, the spectra still have a linearly increasing post edge (with EXAFS oscillations superimposed on it), and the slope of the n-XAS and p-XAS post-edge lines are different. In this case simply multiplying the n-XAS and p-XAS by constants will never give an XMCD spectrum that is zero in the post edge region. There is then some component of the XAS background that is not accounted for by linear subtraction and multiplication by a constant. It seems to me that flattening could be a good way to account for such a background. So is flattening a reasonable thing to do in a case such as this, or is there a better way to account for such a background? Thanks, George On Wed, May 15, 2013 at 11:41 AM, Matthew Marcus <mamarcus(a)lbl.gov> wrote: > The way I commonly do pre-edge is to fit with some form plus a power-law > singularity representing the initial rise of the edge, then > subtract out that "some form". Now, that form can be either linear, > linear+E^(-2.7) (for transmission), or linear+ another power-law > singularity centered at the center passband energy of the fluorescence > detector. That latter is for fluorescence data which is affected by > the tail of the elastic/Compton peak from the incident energy. Whichever > form is taken gets subtraccted from the whole data range, resulting > in data which is pre-edge-subtracted but not yet post-edge normalized. > The path then splits; for EXAFS, the usual conversion to k-space, spline > fitting in the post-edge, subtraction and division is done, all > interactively. Tensioned spline is also available due to request of a > prominent user. > For XANES, the post-edge is fit as previously described. Thus, there's no > distinction made between data above and below E0 in XANES, whereas > there is such a distinction in EXAFS. > mam > > > On 5/15/2013 8:25 AM, Matt Newville wrote: > >> Hi Matthew, >> >> On Wed, May 15, 2013 at 9:57 AM, Matthew Marcus <mamarcus(a)lbl.gov> wrote: >> >>> What I typically do for XANES is divide mu-mu_pre_edge_line by a linear >>> function which goes through the post-edge oscillations. >>> This division goes over the whole data range, including pre-edge. If the >>> data has obvious curvature in the post-edge, I'll use a higher-order >>> polynomial. For transmission data, what sometimes linearizes the >>> background >>> is to change the abscissa to 1/E^2.7 (the rule-of-thumb absorption >>> shape) and change it back afterward. All this is, of course, highly >>> subjective and one of the reasons for taking extended XANES data (300eV, >>> for instance). For short-range XANES, there isn't enough info to do more >>> than divide by a constant. Once this is done, my LCF programs allow >>> a slope adjustment as a free parameter, thus muNorm(E) = >>> (1+a*(E-E0))*Sum_on_ref{x[ref]***muNorm[ref](E)}. A sign that this >>> degree of >>> freedom >>> may be being abused is if the sum of the x[ref] is far from 1 or if >>> a*(Emax-E0) is large. Don't get me started on overabsorption :-) >>> mam >>> >> >> Thanks -- I should have said that pre_edge() can now do a >> victoreen-ish fit, regressing a line to mu*E^nvict (nvict can be any >> real value). >> >> Still, it seems that the current flattening is somewhere between >> "better" and "worse", which is unsettling... Applying the >> "flattening" polynomial to the pre-edge range definitely seems to give >> poor results, but maybe some energy-dependent compromise is possible. >> >> And, of course, over-absorption is next on the list! >> >> --Matt >> ______________________________**_________________ >> Ifeffit mailing list >> Ifeffit(a)millenia.cars.aps.anl.**gov <Ifeffit(a)millenia.cars.aps.anl.gov> >> http://millenia.cars.aps.anl.**gov/mailman/listinfo/ifeffit<http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit> >> >> ______________________________**_________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.**gov <Ifeffit(a)millenia.cars.aps.anl.gov> > http://millenia.cars.aps.anl.**gov/mailman/listinfo/ifeffit<http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit> >

1 0