http://permalink.gmane.org/gmane.science.physics.ifeffit hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.science.physics.ifeffit/1875 <pre>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&amp;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</pre> Kevin Jorissen 2013-05-16T16:52:23 http://permalink.gmane.org/gmane.science.physics.ifeffit/1874 <pre>That 'flattening' function seems over-complicated to me and makes an artificial discontinuity, at least in slope, at E0 which is a somewhat arbitrary quantity. Why not simply divide by the post-edge quadratic (norm(E) = (mu(E)-pre_edge_line(E))/quadratic(E))? In some cases, where there's a big curvature, it may make sense to divide mu(E) by the quadratic, then subtract a pre-edge. What I've never solved satisfactorily is the case in which the extrapolation of the pre-edge line crosses the post-edge, so mu(E)-pre_edge_line(E)&lt;0 for some part of the range. I've never understood why this happens. mam On 5/16/2013 4:47 AM, Matt Newville wrote: </pre> Matthew Marcus 2013-05-16T16:37:36 http://permalink.gmane.org/gmane.science.physics.ifeffit/1873 <pre>Hi Matthew, George, Zach, Thanks for the discussion! On Wed, May 15, 2013 at 5:41 PM, Matthew Marcus &lt;mamarcus-/3juihCSby0&lt; at &gt;public.gmane.org&gt; wrote: Sorry, I should have been clearer. "Standard Athena/Ifeffit" is to a) regress a pre-edge line to mu(E) (no power laws) b) regress a post-edge quadratic c) set edge_step = post_edge_quadratic(E0) - pre_edge_line(E0) b) set norm(E) = (mu(E) - pre_edge_line(E)) / edge_step. Flattening (Athena only, now backported to larch) fits a quadratic to the post-edge range (typcically E0+100 to end of data) of norm(E), and then sets flattened(E) = norm(E) for E&lt;= E0 = norm(E) - quadratic(E) + quadratic(E0) for E &gt; E0 I think this was originally meant for display purposes only. Hopefully Bruce can correct me if I'm wrong on any of the details here. I think it's fair to say that the "Standard Athena/Ifeffit" approach to normalization is simple-minded. It was designed for EXAFS in an era when accessing databases seemed like a challe</pre> Matt Newville 2013-05-16T11:47:17 http://permalink.gmane.org/gmane.science.physics.ifeffit/1872 <pre>I'm not sure what 'flattening' means. Does that mean dividing by a linear or other polynomial function, fitted to the post-edge? mam On 5/15/2013 1:43 PM, George Sterbinsky wrote: 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 the n some </pre> Matthew Marcus 2013-05-15T22:41:00 http://permalink.gmane.org/gmane.science.physics.ifeffit/1871 <pre>By standard normalization, I meant subtraction of a linear pre-edge and multiplication by a constant. If this treatment is applied to the XAS spectra before subtraction, one does not obtain an XMCD spectrum that goes to zero in the post edge region for the data I described. As you noted, that is what would be expected given the p-XAS and n-XAS have different slopes in the post-edge region. On the other hand, standard normalization + flattening does result in pre and post-edge regions that go to zero, again as one might expect. So perhaps, the background modeled by standard normalization + flattening is an accurate representation of the real background in some cases and can be used in quantitative analysis. Is there reason to believe that cannot be the case? Thanks, George On Wed, May 15, 2013 at 3:04 PM, Matthew Marcus &lt;mamarcus-/3juihCSby0&lt; at &gt;public.gmane.org&gt; wrote: _______________________________________________ Ifeffit mailing list Ifeffit-yJARRRr6MatTopXEvdbuMochTzHAynqa8htcxDm17Xw&lt; at &gt;public.gmane.org </pre> George Sterbinsky 2013-05-15T20:43:42 http://permalink.gmane.org/gmane.science.physics.ifeffit/1870 <pre>OK, I guess I don't know what 'standard normalization' is. It looks from the quotient that you'll need some sort of curved post-edge. I guess the division didn't work because the electron energy distribution is different pre- and post-edge, so the magnetic effects are different and vary across the edge. Thus, the shapes of the MCD peaks will be at least a little corrupted even if the pre- and post-edge spectra are taken into account. I don't know what to do about this. Did you try asking Elke? mam On 5/15/2013 11:52 AM, George Sterbinsky wrote: S 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 </pre> Matthew Marcus 2013-05-15T19:04:26 http://permalink.gmane.org/gmane.science.physics.ifeffit/1869 <pre>Hi Matthew, On Wed, May 15, 2013 at 1:20 PM, Matthew Marcus &lt;mamarcus-/3juihCSby0&lt; at &gt;public.gmane.org&gt; wrote: Sorry, I think my wording wasn't particularly clear here. What I should have said is: "The goal then is to subtract the *normalized* XAS measured in a positive field (p-XAS) from *normalized* XAS measured in a negative field (n-XAS) and get something (the XMCD) that is zero in the pre-edge and post-edge regions. *However, standard normalization does not give this result*" Italics indicate new text. I would agree, I think the effect of the magnetic field on the electrons is the likely source of the differences in background. No, after division of the p-XAS by the n-XAS (before any normalization), both the pre and post-edge regions are smooth, but one would need a step-like function to connect them. I've attached a plot showing the result of division. If that miracle occurs, Thanks for the suggestion and your reply. George _______________________________________________ Ifeffit m</pre> George Sterbinsky 2013-05-15T18:52:36 http://permalink.gmane.org/gmane.science.physics.ifeffit/1868 <pre>Hi Matthew, On Wed, May 15, 2013 at 1:20 PM, Matthew Marcus &lt;mamarcus-/3juihCSby0&lt; at &gt;public.gmane.org&gt; wrote: Sorry, I think my wording wasn't particularly clear here. What I should have said is: "The goal then is to subtract the *normalized* XAS measured in a positive field (p-XAS) from *normalized* XAS measured in a negative field (n-XAS) and get something (the XMCD) that is zero in the pre-edge and post-edge regions. *However, standard normalization does not give this result*" Italics indicate new text. I would agree, I think the effect of the magnetic field on the electrons is the likely source of the differences in background. No, after division of the p-XAS by the n-XAS, both the pre and post-edge regions are smooth, but one would need a step-like function to connect them. I've attached a plot showing the result of division. If that miracle occurs, Thanks for the suggestion and your reply. George _______________________________________________ Ifeffit mailing list Ifeffit-yJARR</pre> George Sterbinsky 2013-05-15T18:13:10 http://permalink.gmane.org/gmane.science.physics.ifeffit/1867 <pre>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 fro m 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 sp! ectra that were indi</pre> Zack Gainsforth 2013-05-15T17:59:08 http://permalink.gmane.org/gmane.science.physics.ifeffit/1866 <pre>You say that the flipping difference (p - n) is 0 in pre-edge and far post-edge regions, which is as it should be, but then say that the slopes of p- and n- post-edges, considered separately, are different. I must be misunderstanding because those two statements would seem to be inconsistent. I wonder if the sensitivity of the TEY changes with magnetic field because of the effect of the field on the trajectories of the outgoing electrons, which would explain the differing curves. A possibility - if you divide the p-XAS by n-XAS, do you get something which is a smooth curve everywhere but where MCD is expected? Does that curve match in pre- and far post-edge regions? If that miracle occurs, then perhaps you could fit that to a polynomial, except in the MCD region, then divide the p-XAS by that polynomial, to remove the effect of the differing sensitivities. There are people here at ALS, such as Elke Arenholz &lt;earenholz-/3juihCSby0&lt; at &gt;public.gmane.org&gt;, who do this sort of spectroscopy. I suggest asking he</pre> Matthew Marcus 2013-05-15T17:20:36 http://permalink.gmane.org/gmane.science.physics.ifeffit/1865 <pre>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 accou</pre> George Sterbinsky 2013-05-15T16:58:53 http://permalink.gmane.org/gmane.science.physics.ifeffit/1864 <pre>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</pre> Matthew Marcus 2013-05-15T15:41:55 http://permalink.gmane.org/gmane.science.physics.ifeffit/1863 <pre>Hi Matthew, On Wed, May 15, 2013 at 9:57 AM, Matthew Marcus &lt;mamarcus-/3juihCSby0&lt; at &gt;public.gmane.org&gt; wrote: 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 </pre> Matt Newville 2013-05-15T15:25:23 http://permalink.gmane.org/gmane.science.physics.ifeffit/1862 <pre>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:</pre> Matthew Marcus 2013-05-15T14:57:14 http://permalink.gmane.org/gmane.science.physics.ifeffit/1861 <pre>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</pre> Matt Newville 2013-05-15T14:35:41 http://permalink.gmane.org/gmane.science.physics.ifeffit/1860 <pre>Bruce, I have also seen a difference between old and new Artemis, but I have one additional bit of information that may be useful: in my case the good fit is decidedly from the new version. I have tried to reproduce fits in Artemis that someone else made in WinXAS. The samples included some well-characterized published mineral standards, for which the WinXAS fit agreed with the published model. I could not reproduce these fits with the old Artemis - sometimes the fit would zoom off to something unphysical, but often it would settle on something plausible but different. We never found a satisfactory explanation for this behavior. Redoing the same work in Demeter Artemis, I can consistently reproduce the WinXAS fits. I did not import the old files; I built new ones, but used the same data and feff input files as before. I am working in Windows, but it's been pretty much the same under three different operating systems (XP, Vista, 7). I am having trouble finding the old fit files to attach, but I could pro</pre> Baker, Leslie 2013-05-14T15:00:25 http://permalink.gmane.org/gmane.science.physics.ifeffit/1859 <pre>Hi Bruce, Thanks a lot for looking into this. at least i know I'm not going crazy. But yes, if it might be relevant i'm on a machine running windows 7. I appreciate your feedback regarding my fitting model, I was playing around with the fit and trying to minimize the amount of variables, and this was the best I got. I'll take into account your suggestions and revisit my fit (i had set it aside after difficulties of trying to import it into the newer version of Artemis). Look forward to hearing what causes the differences between versions and even operating systems! thanks, georges On Mon, May 13, 2013 at 11:19 PM, Bruce Ravel &lt;bravel-IGkKxAqZmp0&lt; at &gt;public.gmane.org&gt; wrote: _______________________________________________ Ifeffit mailing list Ifeffit-yJARRRr6MatTopXEvdbuMochTzHAynqa8htcxDm17Xw&lt; at &gt;public.gmane.org http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit </pre> Georges Siddiqi 2013-05-14T12:38:31 http://permalink.gmane.org/gmane.science.physics.ifeffit/1858 <pre> More info: the behavior on my linux machine is differnt from Windows. The difference in the fit result is subtle on Linux and quite enormous on Windows. I am not sure which part of that confuses me more. I'll keep looking into it. B </pre> Bruce Ravel 2013-05-13T21:19:32 http://permalink.gmane.org/gmane.science.physics.ifeffit/1857 <pre> Georges, Sorry for the lengthy delay. Beamline, travel, etc -- I just haven't had a chance to look into software issues until this week. I agree that the fits are being evaluated slightly differently in the old and new versions of the code. As you say, best fit values and statistical parameters are somewhat different. I am not sure I agree that they are "nowhere near similar", but the disrepancy is much larger than a mere numerical difference. I am not yet clear what is going on, but I am looking into it. If I may comment a bit more broadly on the project you sent me, I have some concerns about your fitting model. I would not agree that your fit is "good" using either version of Artemis. Or perhaps I should say that you and I may not have the same expectation of what "good fit" means. The central problem in your fitting model is that you are using the same parameter for sigma^2 for all your paths, which include O, C, and N atoms spread over a distance range from 1.69 A to 2.03 A. Similarly, you us</pre> Bruce Ravel 2013-05-13T20:19:05 http://permalink.gmane.org/gmane.science.physics.ifeffit/1856 <pre>Hi Bruce, Thanks for the message ! I fully agree with you regarding the first column of data files. At the end, I was averaging my data files with written macro but seems it would be much more easier to process the files directly. I highly appreciate your efforts towards the solution of this problem. Thank a ton ! Best regards Atul -----Original Message----- From: Bruce Ravel Sent: Monday, May 13, 2013 8:49 PM To: XAFS Analysis using Ifeffit Subject: Re: [Ifeffit] Athena- Demeter 0.9.14 importing data On Saturday, May 04, 2013 05:21:51 PM abansode&lt; at &gt;iciq.es wrote: Atul, You are correct. Athena does the wrong thing when importing multiple files. Although it remembers your column selection, it keeps resetting the choice of energy units. As Matt pointed out, the reason for this is the annoying and useless first column of your data files. Point number? That's kind of silly. Athena attempts to use some smarts when importing data. One of the tests it does is on the contents of the first column in an </pre> abansode-Q6yBblmTZA8< at >public.gmane.org 2013-05-13T19:47:43 http://permalink.gmane.org/gmane.science.physics.ifeffit/1855 <pre> Well, that didn't take long. Thanks, Atul, for discovering and reporting this bug. B </pre> Bruce Ravel 2013-05-13T19:05:44 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.science.physics.ifeffit