[Ifeffit] Ifeff calculation

Dien.Li at srnl.doe.gov Dien.Li at srnl.doe.gov
Wed Aug 15 08:42:30 CDT 2018


Hi, Carlo and Matt or others

Attached please find the cif crystal structure data file for NaReO4 that was downloaded from Crystallography Open database. As I added it into Artemis for calculation, it gave error message saying that it has more than 500 atoms that exceeds the limit. Could you help to troubleshooting?? Thanks a lot.


Dien Li

-----Original Message-----
From: Ifeffit <ifeffit-bounces at millenia.cars.aps.anl.gov> On Behalf Of ifeffit-request at millenia.cars.aps.anl.gov
Sent: Tuesday, August 14, 2018 5:29 PM
To: ifeffit at millenia.cars.aps.anl.gov
Subject: Ifeffit Digest, Vol 186, Issue 13

Send Ifeffit mailing list submissions to
	ifeffit at 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 at millenia.cars.aps.anl.gov

You can reach the person managing the list at
	ifeffit-owner at 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. Re: LCF on Larch - EXAFS Region (Matt Newville)
   2. Re: wavelet transforms for EXAFS (Matt Newville)


----------------------------------------------------------------------

Message: 1
Date: Tue, 14 Aug 2018 12:33:35 -0500
From: Matt Newville <newville at cars.uchicago.edu>
To: XAFS Analysis using Ifeffit <ifeffit at millenia.cars.aps.anl.gov>
Subject: Re: [Ifeffit] LCF on Larch - EXAFS Region
Message-ID:
	<CA+7ESbr8s-gQOeLOo302hTdtT+XLS8g55goXvYm6hqJFiLCkaQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Martin and Mike,

Thanks -- I'll take a closer look at your paper on this!   I think we all
basically agree that linear analysis of EXAFS can work, but also that
compared to linear analysis of XANES, linear analysis of EXAFS has a few
more caveats and issues that need to be addressed for each case.

On Mon, Aug 13, 2018 at 8:26 PM Martin McBriarty <memcbr at gmail.com> wrote:

> Matt,
>
> Glad to read your impressions of EXAFS LCF. I've had reasonable success
> with LCF using EXAFS spectra generated by ab initio molecular dynamics
> (AIMD) to figure out the local structure of dopants whose preferred
> coordination is symmetrically dissimilar from the crystals they inhabit,
> i.e. for which there are no good experimental standards. This can be pretty
> tough to do accurately with shell-by-shell fitting.
>
> As you point out, disorder is a huge hurdle (in both LCF and
> shell-by-shell EXAFS analysis). We assume that a good AIMD model will
> simulate thermal disorder pretty well, but there are likely differences in
> configurational disorder between a periodic infinite structure and the real
> material due to defects. Fortunately, defects can be explicitly accounted
> for in a simulation, assuming you have the computational capability to
> screen a set of defect configurations.
>
> Background subtraction should ideally be done using the same procedure for
> all data. Theoretical data could be used to refine a background subtraction
> procedure; spline fit parameters such as Rbkg or clamping may be tweaked to
> improve agreement between a simulated chi(k) and a measured standard over a
> reasonable k-range.
>
> Simulating spectra with a range of binding energy offsets can explicitly
> address the problem of E0 choice, but it can also be used as a fudge factor
> for strain. In my LCFs, dE0 is the only parameter besides the fractions of
> the chosen phases.
>
> To address the above problems, benchmarking is key. Quantitative agreement
> should be sought between simulated spectra and experimental standards to
> ensure the theory is sound and the chi(k) extraction is reasonable.
> However, there are probably still systematic sources of error which are
> larger than the uncertainties Athena's LCF tool will report; I agree with
> Mike's practical estimate of 10% or so.
>
> I discuss these issues in somewhat greater detail in my recent (open
> access!) article that demonstrates how LCF using AIMD-simulated spectra
> yields answers that shell-by-shell fitting struggles with due to multiple
> overlapping components: https://pubs.acs.org/doi/10.1021/acs.est.8b00297
>
> Martin
>
>
> On Sun, Aug 12, 2018 at 10:19 PM, Matt Newville <
> newville at cars.uchicago.edu> wrote:
>
>> Hi Mike,
>>
>> On Thu, Aug 9, 2018 at 10:04 PM Mike Massey <mmassey at gmail.com> wrote:
>>
>>> This is interesting. Could you say more about your skepticism of the
>>> robustness of EXAFS LCF, Matt?
>>>
>>> To be fair, it suffers from many of the same drawbacks of XANES LCF,
>>> plus others. But I'm curious about your thoughts on it since yours seems to
>>> be what amounts to a "strong opinion" on the subject.
>>>
>>
>>
>> I would not say that no one should ever do linear combination fitting for
>> EXAFS.  For sure, linear analysis of XANES is quite robust and verified
>> many times to give good results, at least at level of a few percent.
>> Linear analysis of EXAFS suffers more data processing challenges and
>> conceptual problems that limit its robustness.  For sure, there are cases
>> for which it can work well.
>>
>> Longer answer:
>> Any linear analysis (LCF, PCA, MCR-ALS, etc) of XANES works reasonably
>> well (typically to a few percent) because:
>>    a) the processing needed is minimal.  Data need to have a common
>> energy calibration better than the intrinsic energy resolution -- typically
>> energy calibration of 0.25 eV or better will be OK.  Data need to have a
>> consistent normalization of mu(E), typically to a few percent.   Variations
>> in these processing steps will have a direct and negative effect on the
>> results.
>>
>>    b) conceptually, the assumption is that there exists a nearly 1 to 1
>> correspondence between "local chemical configuration" and "measured XANES",
>> and that the "local chemical configurations" that are being investigated
>> are discrete and well-defined (ie "iron carbonate") and not continuous.
>>  That is, if you determine that your Fe XANES spectra is "50% iron
>> carbonate and 50% iron sulfate" then implicit conclusion is that 50% of the
>> iron atoms are iron carbonate and 50 percent are iron sulfate, not that all
>> irons are 50% carbonate and 50% sulfate.
>>
>> To be clear, linear analysis of XANES does not work well to ppm levels,
>> partly due to the poor experimental contrast (that is, mu(E) tend to all
>> look alike and features are intrinsically broadened to the ~eV level), but
>> also conceptually, because at the ppm level, local chemical configurations
>> are not always limited to 3 to 10 discrete states.
>>
>> Linear Combination EXAFS is more challenging from both the processing and
>> conceptual point of view.
>>
>> For Processing, EXAFS requires more data processing than XANES.  The
>> selection of E0 and the background mu0(E) will have an effect on linear
>> analysis of EXAFS if not done consistently.  It is not really obvious how
>> E0 or mu0(E) can be selected consistently for very different spectra.
>>
>> Conceptually, EXAFS is much more sensitive to disorder and subtle
>> variations in the bond lengths (thermal or static disorder) and can have
>> significant variation in its sensitivity to second and further neighbors.
>>  In that sense, EXAFS is much less discrete and much more continuous in its
>> variability across different kinds of local structures.
>>
>> Again, this is not to say that linear analysis of EXAFS cannot ever work,
>> just that is probably more limited in applicability and absolute accuracy
>> than linear analysis of XANES.  Of course, for EXAFS you can also do an
>> actual fit of structural parameters.  The information content is somewhat
>> limited so that refining multiple overlapping components may not always be
>> possible, and linear combinations of end-member spectra may look
>> attractive....
>>
>> Hopefully, anyone who has other insights or experiences will be able to
>> correct any of my misunderstandings.
>>
>> --Matt
>>
>>
>> _______________________________________________
>> Ifeffit mailing list
>> Ifeffit at millenia.cars.aps.anl.gov
>> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
>> Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit
>>
>>
> _______________________________________________
> Ifeffit mailing list
> Ifeffit at millenia.cars.aps.anl.gov
> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
> Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit
>


-- 
--Matt Newville <newville at cars.uchicago.edu> 630-252-0431
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://millenia.cars.aps.anl.gov/pipermail/ifeffit/attachments/20180814/aa8ae8ca/attachment-0001.html>

------------------------------

Message: 2
Date: Tue, 14 Aug 2018 16:27:52 -0500
From: Matt Newville <newville at cars.uchicago.edu>
To: XAFS Analysis using Ifeffit <ifeffit at millenia.cars.aps.anl.gov>
Subject: Re: [Ifeffit] wavelet transforms for EXAFS
Message-ID:
	<CA+7ESbo9EHxFJB9aHFxSTtztsoLeKc123USFV6-8FD+WANRGaw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Adam,

On Tue, Aug 14, 2018 at 7:07 AM Clark Adam Hugh (PSI) <adam.clark at psi.ch>
wrote:

> Hi Matt
>
>
>
> I recently had some problems incorporating the larch Cauchy wavelet
> transform into my program for rapid bulk processing of QEXAFS data
> (discussed
> http://millenia.cars.aps.anl.gov/pipermail/ifeffit/2014-April/007250.html).
> I particular after importing the relevant module into python the
> cauchy_wavelet(cwsam, kweight=kwwt, _larch=mylarch) function raises the
> error ?not callable?. As a work around I have explicitly copied the module
> code for the definition into my own script and this seems to resolve the
> issue.
>

A minimal example that shows the problem would be helpful, but I think I
can guess what is going on.  Basically, the python API for lots of the XAFS
(and plotting) functionality in larch should be cleaned-up.   My focus has
been on making the commands usable as larch commands, but the python API
has lots of inconsistencies.   That said, this works for me:

    import larch
    from larch_plugins.io import read_ascii
    from larch_plugins.xafs import autobk
    from larch_plugins.xafs.cauchy_wavelet import cauchy_wavelet

    import matplotlib.pyplot as plt

    _larch = larch.Interpreter()

    dat = read_ascii('feo_xafs.dat', _larch=_larch)
    autobk(dat, rbkg=0.9, kweight=2, _larch=_larch)
    cauchy_wavelet(dat, kweight=2, _larch=_larch)

    plt.imshow(dat.wcauchy_mag)
    plt.show()

That is, I would bet that the 'not callable' you are seeing is because of
the poorly exposed "cauchy_wavelet" call.   Does that match what you are
seeing?

> I also notice that at present that it is not possible to apply a windowing
> function within the wavelet transform, is this just a case of windowing the
> K space data that is fed to the module? I would also have interest in
> trying to fit the EXAFS data in the wavelet space, has there been any
> progress in Larch for performing this?
>

Yes, right now there is not a window function applied.   We could add
that.  From talking with you and a couple other people at the XAFS
conference, and other folks since then, it does seem that adding the Morlet
wavelet would be worth doing too.  I'm not sure I have the code for this.
Do you?

You can definitely fit EXAFS in wavelet space, just using
"feffit_transform(fitspace='w', ....)".     There's an example of this at


https://github.com/xraypy/xraylarch/blob/master/examples/feffit/doc_feffit_wavelet_fit.lar



>
>
> As briefly discussed at the EXAFS conference another feature that I think
> would be very nice to include would be the possibility to use a Victoreen
> function for the post edge normalisation instead of a polynomial function.
> I also briefly discussed the application of the MBACK algorithm. Unless I
> am doing something incorrect, when trying to use the MBACK algorithm in
> Larch within python the following error is raised ? ?XrayDB? object has no
> attribute _getChantler?. In some cases it would be very interesting to
> apply the MBACK algorithm particularly when only a short data range is
> collected in some experiments.
>

Yes, I remember that conversation well, and agree that getting some better
normalization using tabulated mu/rho is a good idea.  And, sorry about the
error from XrayDB in the released version.  This is now fixed in github.

I've been playing with normalization with tabulated mu/rho with the MBACK
algorithm. I think there are potential issues with this, in that MBACK
includes both a pre-edge that tries to compensate for Compton scattering
leaking into the fluorescence signal *and* normalization using tabulated
mu/rho.  Especially when using a Victoreen pre-edge, I think that the
compensation for Compton scattering can sort of cause instabilities, though
I haven't explored this for a wide range of spectra.
But I recently (like, in the past week) added a "mback_norm" function to do
only the normalization using tabulated mu/rho.   This is now in the github
master branch and partially supported in the github-version of
XAS_Viewer.    But, this definitely needs more study and more work.

If you're interested in looking at this in more detail, let me know or
check out the github master repo.
Or, if you're more interested in the wavelet transforms, please work on
that!

Cheers,

--Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://millenia.cars.aps.anl.gov/pipermail/ifeffit/attachments/20180814/5dd172db/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
Ifeffit mailing list
Ifeffit at millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit


------------------------------

End of Ifeffit Digest, Vol 186, Issue 13
****************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NaReO4_5910163.cif
Type: application/octet-stream
Size: 2660 bytes
Desc: NaReO4_5910163.cif
URL: <http://millenia.cars.aps.anl.gov/pipermail/ifeffit/attachments/20180815/f76e2cfe/attachment-0001.obj>


More information about the Ifeffit mailing list