Re: [Ifeffit] Trouble downloading Demeter for mac

[Matt Newville]

Hi Christopher,

Installing Demeter on macOS has always been painful.  The MacPorts solution
can work sometimes, but it does require some expertise to use MacPorts and
to think about the software as something that needs to be compiled and
built.Some of the packages needed (especially "ifeffit" and "wxPerl")
are just not very well supported.  At this point, I cannot recommend using
the old ifeffit - it has too many known issues that will not be fixed.

I know that using a virtual Windows interface like Parallels works for some
people.

But, if you are just getting started, I highly recommend installing Larch,
either using the installer at
https://urldefense.us/v3/__https://xraypy.github.io/xraylarch/installation.html__;!!G_uCfscf7eWS!fZTlh9DYpgNhCtGT_yyfrzfF4yE1l8leptz7e3M3aKGakaOPFXtoXNk2EveNhEfOu4gXfi_8iEODoh7wVDJMrZgmJhgvvf6gaE6s2T8$
  (you'll have to go
into Privacy & Security and allow the installer from "an untrusted source"
to run. Also, it might say that it has less than a minute to go for about 5
minutes ;) ), or by downloading and running the GetLarch script at
https://urldefense.us/v3/__https://xraypy.github.io/xraylarch/installation.html*install-scripts__;Iw!!G_uCfscf7eWS!fZTlh9DYpgNhCtGT_yyfrzfF4yE1l8leptz7e3M3aKGakaOPFXtoXNk2EveNhEfOu4gXfi_8iEODoh7wVDJMrZgmJhgvvf6g0LgQm-I$
  and
running that from a Terminal.

With this installed, the Larix App (in the Larch folder on your Desktop:
also, the first launch might take a minute) will run and do basically
everything that Athena and Artemis do.  There are some differences, and
there may be a missing feature or two, but many things are better.  In
general, comments, complaints, and suggestions are welcome.  We aim for
"highly compatible and familiar"  with Demeter and "better than" the
underlying ifeffit library.

And, it does install and run on macOS. It turns out that most of the
development and testing happens on macOS.

Cheers,

--Matt


On Wed, May 8, 2024 at 2:54 PM Christopher Reitwiesner <
christopher.reitwies...@uconn.edu> wrote:

> Hello!  I am an undergraduate researcher looking to utilize Demeter.
> Unfortunately I only have access to a mac. I followed the instructions on
> the github page. Downloading MacPorts went fine, so did installing Command
> Line Developer Tools.
> ZjQcmQRYFpfptBannerStart
> This Message Is From an External Sender
> This message came from outside your organization.
>
> ZjQcmQRYFpfptBannerEnd
> Hello!
> I am an undergraduate researcher looking to utilize Demeter. Unfortunately
> I only have access to a mac. I followed the instructions on the github
> page. Downloading MacPorts went fine, so did installing Command Line
> Developer Tools. However when trying to install demeter from Terminal, I
> eventually run into this error message:
>
> Building ifeffit
>
> Error: Failed to build ifeffit: command execution failed
>
> Error: See
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_ifeffit/ifeffit/main.log
> for details.
>
> Error: Follow 
> https://urldefense.us/v3/__https://guide.macports.org/*project.tickets__;Iw!!G_uCfscf7eWS!fZTlh9DYpgNhCtGT_yyfrzfF4yE1l8leptz7e3M3aKGakaOPFXtoXNk2EveNhEfOu4gXfi_8iEODoh7wVDJMrZgmJhgvvf6guCVdmxY$
>  
> <https://urldefense.us/v3/__https://guide.macports.org/*project.tickets__;Iw!!G_uCfscf7eWS!c5WD9EctbB1ulj6KaFVuSPjLpPPErmMNEGd1mpXSlnKoQJ-l_rYaPwN-K2a1xRrR4k5PZptZYkzxXNWun2jrsBNCGOjNjcOdorMahD-iqHI$>
> if you believe there
>
> is a bug.
>
> Error: Processing of port demeter failed
>
>
>
> I am at a loss on where to go from here and was wondering if someone could
> point me in the right direction.
>
>
> Thank you for your time!
>
> Christopher Reitwiesner
> ___
> Ifeffit mailing list
> Ifeffit@millenia.cars.aps.anl.gov
> https://urldefense.us/v3/__http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit__;!!G_uCfscf7eWS!fZTlh9DYpgNhCtGT_yyfrzfF4yE1l8leptz7e3M3aKGakaOPFXtoXNk2EveNhEfOu4gXfi_8iEODoh7wVDJMrZgmJhgvvf6gZfj5pa4$
>  
> Unsubscribe: 
> https://urldefense.us/v3/__http://millenia.cars.aps.anl.gov/mailman/options/ifeffit__;!!G_uCfscf7eWS!fZTlh9DYpgNhCtGT_yyfrzfF4yE1l8leptz7e3M3aKGakaOPFXtoXNk2EveNhEfOu4gXfi_8iEODoh7wVDJMrZgmJhgvvf6gnMoE5dM$
>  
>


-- 
--Matt Newville  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Difficulty with normalization of XAS spectra

[Matt Newville]

Hi Jesse,

OK, I think this is now fixed in the development version.
If you're up for it, you can install the latest version (updated daily) by
finding the Python for your xraylarch installation (maybe
C:\Users\yournamae\xraylarch\bin\python) and doing

python -m pip install
https://urldefense.us/v3/__https://millenia.cars.aps.anl.gov/xraylarch/downloads/xraylarch-latest-py3-none-any.whl__;!!G_uCfscf7eWS!eo1MYVGYChGZ8xhX8-NpgYBrM-O05XDU41Ay4lA0CkG9978sopUg5hJcpeis-R1i5R8kfH55Y-KObTDIn3fwa-yf9KGbhVWtT7ETsSw$
 



On Sat, Apr 13, 2024 at 10:29 AM jesse walters 
wrote:

> Hi all, I have some spectra collected by a collaborator, Francesco
> Ressico, a PhD student at Uni Bologna,  (see attached .h5 file below) and
> we are having trouble normalizing the Fe K edge spectra. The data are for
> serpentine group minerals
> ZjQcmQRYFpfptBannerStart
> This Message Is From an External Sender
> This message came from outside your organization.
>
> ZjQcmQRYFpfptBannerEnd
> Hi all,
>
> I have some spectra collected by a collaborator, Francesco Ressico, a PhD
> student at Uni Bologna,  (see attached .h5 file below) and we are having
> trouble normalizing the Fe K edge spectra. The data are for serpentine
> group minerals and were collected in fluorescence mode. In the attached
> file, the correct X array value is 'energy_enc', the data type is 'xas',
> and the y array should be 'mu_fluo_det0'. The spectra are already
> normalized for the incoming beam energy (although this can also be done
> using 'flou_det0/i0'). There are multiple spectra in the file, any one of
> them can be chosen to test the procedure.
>
> After loading the spectra, I am able to plot the raw spectra correctly
> (see attached). But when I try to normalize the pre and post edge regions
> and plot the normalized spectra, the software only gives a blank plot. I
> have tried changing the normalization type, polynomial type, range, etc for
> both the pre and post edge, but nothing seems to work. I also tested
> different spectra, but with similar results.
>
> Does anyone have suggestions for how these data can be normalized?
>
> The h5 file is too large, so here is a dropbox link
> https://urldefense.us/v3/__https://www.dropbox.com/scl/fi/d8k5s67vli0mq97ac520y/COR21_79_Xastransect_79_F1_THC.h5?rlkey=33ragg4p6x9rx65t9yvi5kewe=0__;!!G_uCfscf7eWS!eo1MYVGYChGZ8xhX8-NpgYBrM-O05XDU41Ay4lA0CkG9978sopUg5hJcpeis-R1i5R8kfH55Y-KObTDIn3fwa-yf9KGbhVWtR3zz5X4$
>  
> <https://urldefense.us/v3/__https://www.dropbox.com/scl/fi/d8k5s67vli0mq97ac520y/COR21_79_Xastransect_79_F1_THC.h5?rlkey=33ragg4p6x9rx65t9yvi5kewe=0__;!!G_uCfscf7eWS!btLKhnEiyp5gMQfSDnHdxqgt2ie5vcVHW7e142vokJ-wEX6zZSIOcAyHsf5THg9ZlyyIsx7Vfm27ycKWAQg1_cysDdnW65aCQA$>
>
> Sincerely,
> Jesse Walters
>
> --
> Jesse B. Walters
> Ambizione Fellow
> Institut für Geologie
> Universität Bern
> ___
> Ifeffit mailing list
> Ifeffit@millenia.cars.aps.anl.gov
> https://urldefense.us/v3/__http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit__;!!G_uCfscf7eWS!eo1MYVGYChGZ8xhX8-NpgYBrM-O05XDU41Ay4lA0CkG9978sopUg5hJcpeis-R1i5R8kfH55Y-KObTDIn3fwa-yf9KGbhVWtulTLRdY$
>  
> Unsubscribe: 
> https://urldefense.us/v3/__http://millenia.cars.aps.anl.gov/mailman/options/ifeffit__;!!G_uCfscf7eWS!eo1MYVGYChGZ8xhX8-NpgYBrM-O05XDU41Ay4lA0CkG9978sopUg5hJcpeis-R1i5R8kfH55Y-KObTDIn3fwa-yf9KGbhVWtBx51I7k$
>  
>


-- 
--Matt Newville  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Peak-Fitting Process in Larix

[Matt Newville]

Hi Ryan,

There are a couple of different questions here.  And it turns out that this
is also coming up against a few small bugs in code that are in the process
of being resolved ;).   I think this is going to be a long answer, first
the "how to do this", then a warning about the bug-let, then on
pseudo-Voigt in general.

First,  on doing peak fitting with arc-tangents in Larix:

> The parameters for the arctangent function are initially estimated using
the 'pick values from plot'
> feature. However, modifying these parameters doesn't result in
corresponding changes in the graph,
> making it difficult to ascertain if it aligns with the data points.
Considering this, would it be acceptable to
> set the arctangent's amplitude to 1 (normalised edge jump) and position
its centre a couple of eV below
> E0?

Yes, you can definitely change the initial values (and set bounds -- but be
careful about setting these too tightly).  Picking default values from the
plot is meant to be a rough value anyway.  The amplitude should be about 1
(and you could set this to be "positive"), and the center is "halfway up
the edge".  These values should refine well.

Be careful using arc-tangents in general.  I know that is what many people
(including Farges et al) used.  I find that "line + Lorentzian" for the
main peak just works better.  But, I also get that you're trying to
reproduce that earlier work, which is fine.  So,  also: note that "fit
baseline" in Larix Pre-Edge Peak Fitting fits that baseline and assigns fit
components named "bline" and "bpeak" ("b" for baseline) -- these are in
your model.  If you want, you can simply delete these components of the
model.

> Following this, two pseudo-Voigt functions are introduced, with their
parameters initially estimated.
> Then, to replicate the conditions of '1.3 eV 2σ width and 45% Gaussian,'
do I set the pseud_fraction
> to 0.45 and pseud_sigma to 2? I'm uncertain about where to input the 1.3
eV width and whether this
> choice is optimal, especially considering that the natural width of the
atomic K level at the Mn edge is
> 1.16 eV (Krause, 1979).

Actually, to reproduce Farge's settings, use 'fraction' of 0.55.  Here
"fraction" is the fraction of the Lorentzian.  Sigma is a little trickier,
because I am not 100% certain of the definition of pseudo-Voigt that they
used.  As far as I can tell, most definitions (and the one we use) have
sigma as the sigma for the Lorentzian (ie, HWFM), and set a sigma for the
Gaussian so that the FWHM are the same for both Lorentzian and Gaussian.
This is not really that well justified physically (more below), but a
common approach. With all that, you should then set the sigma to be 0.65,
so that 2*sigma is 1.3.

I think that is all of the "technical bits" and mechanics of doing the fits.

Second, on buglets:  There are 2 bugs in the combination of lmfit 1.3.0
(latest) and Larix 0.9.75 (latest).  I'm reasonable for both bugs.  Lmfit
1.3.0 is brand new (so, if you're using an older version, wait for 1.3.1
before updating) and breaks the way Larix sets the "arctan" form of the
step function.   A fix is in the works.  A completely separate bug in Larch
0.9.75 bug is the bigger problem, as save/load of Larix sessions with Peak
Fitting results do not correctly restore.  This is fixed in the development
branch, and I hope to push out Larix 0.9.76 in a day or two which will fix
both of these.

> Finally, I couldn't find the specific paper, but the authors stated that
due to the significant processing
>  times required for Voigt functions, they opted for pseudo-Voigt
functions to model instrumental and
> core-hole broadening factors. With improvements in processing times, are
Voigt functions now the
> preferred choice, or does the pseudo-Voigt function still hold advantages
over both?

Third: Voigt functions are a convolution of Lorentzian and Gaussian peaks.
Historically, these have been used in X-ray powder diffraction analysis.
The basic idea is that the energy profile of the X-ray source (say, tube or
bend magnet) gives a broadly Gaussian-like profile of incident angles on a
monochromator. Monochromators at beamlines have complicated profiles, but
are also Gaussian-like (tails get suppressed quickly).  In XRD, I think
that the powder-i-ness of the sample is expected to give Lorentzian-like
broadening of peaks.   For XAS, it is the core-level width that gives a
Lorentzian-like energy profile to a peak.

Properly, the Voigt function needs the complex Faddeeva function (complex
extension of an error function).  In the old days (say pre-2000?),
implementing this was considered either hard (say, if you were writing in
C) or slow to run or, well, the people writing analysis codes were just
lazy ;). So they (I think fullProf may be to blame) invented
pseudo-Voigt as a fraction sum of a Lorentzian and Gaussian of the same
FWHM.   It must have worked well enough -- lots of people use this.

Is there any justification for asserting that the FWHM are 

Re: [Ifeffit] lithium scattering paths

[Matt Newville]

Hi Yang,

That's an interesting report.  One possible explanation is that Larix / XAS
Viewer and Larch use Feff8 by default, while Artemis and (and maybe other
apps?) use Feff6 by default.  That's basically because of when these
versions of Feff were released for us to distribute.

I believe that the consensus view is (and Bruce Ravel has demonstrated this
nicely) that there is very little difference between Feff6 and Feff8 for
EXAFS, with possible exceptions for very heavy elements (say, Z>80).  For
example, self-consistent potentials are shown to be "mostly not very
important" for EXAFS results.

One common observation is that Feff8 is better at allowing hydrogen in
structures -- not so much that Metal-H scattering is important, but just
that the presence of hydrogen often messes up the calculations of the
atomic potentials in Feff6, and Feff8 seems to be noticeably better at that.

But, I am not sure whether Metal-Li has been carefully compared between
Feff6 and Feff8.  Maybe someone here has tried that?   You could try using
Feff6 from the CIF / Feff calculation page in Larix and see if there is a
difference.  I think that would be interesting to document somewhere, maybe
in a paper and/or Jupyter notebook.

--Matt


On Fri, Mar 29, 2024 at 7:54 AM Hu, Yang (HIU)  wrote:

> Dear ifeffit members,
>
>
>
> I would like to ask a few questions about the FEFF calculation and fitting
> of scattering paths between the light lithium (scatters) and transition
> metals (central abs.). For materials containing Li, there are Li scattering
> paths in FEFF calculations, but usually with low “rank” or low
> “importance”.
>
>
>
> Through my limited experience, I often ignored those paths when treating
> cations-disordered materials, where Li share the same crystallographic site
> with other TMs. For the pristine materials, if I include the Li paths, the
> fitting got unstable especially for the paths degeneracy. Things became
> more complicated with Li extraction/insertion in cycled cathode materials.
>
>
>
> Recently I am rechecking previous data (same cif, before XASViewer and now
> Larix), and I could “fit” some spectra with Li paths (the fitted parameters
> were not so crazy), which I never managed before (I tried a lot)… I am
> wondering if there have been developments in FEFF or software that would
> allow better treats of Li scattering paths in shell fitting?
>
>
>
> The behaviour of Li and their influence on the TM local structure are
> quite interesting and important for our works, but I rarely see literature
> involving Li scattering paths. I just don’t know if it is worth continuing
> to invest time and efforts on this..  I really appreciate if you can
> provide some suggestions and opinions J
>
>
>
> Thanks very much,
>
> Best regards,
>
> Yang
>
>
>
>
> ___
> Ifeffit mailing list
> Ifeffit@millenia.cars.aps.anl.gov
> https://urldefense.us/v3/__http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit__;!!G_uCfscf7eWS!c9n3B3H1B1-4JCXjZkXQqhzxYXIBozAhb2mLPwsFmPEgavS4v52e8RnufXEMkBLkWI4XyYi2uxabGOyGV23CpQQZBkJ02L0x-CO2-fY$
>  
> Unsubscribe: 
> https://urldefense.us/v3/__http://millenia.cars.aps.anl.gov/mailman/options/ifeffit__;!!G_uCfscf7eWS!c9n3B3H1B1-4JCXjZkXQqhzxYXIBozAhb2mLPwsFmPEgavS4v52e8RnufXEMkBLkWI4XyYi2uxabGOyGV23CpQQZBkJ02L0xRE6WpHg$
>  
>


-- 
--Matt Newville  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] [IFEFFIT] Polarized FEFF calculation

[Matt Newville]

d
>> fit with a reference RuO2 powder sample), I decided to use the polarization
>> card in my FEFF input. For example, for one of the X-ray angles, the
>> e-field vector would be (1, 0, 0), so I added the line "POLARIZATION 1 0 0"
>> in the FEFF input file.
>>
>> Running this input file gave me a list of paths that had different
>> importance values for each path compared to the non-polarized (isotropic)
>> calculation. *Since "importance" is the relative magnitude of each
>> path's scattering contribution (integration of the chi(k)), I thought that
>> it would be proportional to 3cos^2(θ).* That is, for path i from a FEFF
>> calculation for angle a, the "importance" (abbreviated as "Imp") of that
>> path would be:
>> Imp(a)_i = C(a) * Imp(iso)_i * 3cos^2(θ_i)
>> where C(a) is a constant for each angle that accounts for the fact that
>> importance values are relative (because it is scaled so that the first path
>> in the list has an importance of 100).
>>
>> Now, I wanted to check whether the polarized FEFF calculations really
>> follow this relationship underlined above. So, I tried manually calculating
>> the values of 3cos^2(θ) for two of the paths from the same polarized FEFF
>> calculation, then plug them into the above equation to get C(a). But, as
>> the table below shows, the C(a) values are not the same. FEFF 1 has a
>> disagreement that is small enough to ignore, but the disgareement of C(a)
>> values for The disagreement is small enough to ignore for FEFF 1, but for
>> FEFF 2 and 3 the disagreements are quite large.
>> [image: image.png]
>> *FEFF 1, 2, 3 designate individual polarized FEFF calculations. FEFF 1
>> was with polarization vector = (1, 0, 0). FEFF 2 and 3 were with
>> polarization vector = (0.85, 1.13, 0). For this polarization, the two Ru
>> sites gave different lists of paths.
>>
>> I do think the qualitative trend of the "importance" values in the
>> polarized FEFF calculations is correct, and I can get a bad but
>> not-disastrous fit from simultaneously fitting the data from different
>> angles. However, the above analysis makes me wonder whether the
>> "importance" values from polarized FEFF are truly proportional to
>> 3cos^2(θ), and whether my fitting models for different angles, which I
>> derived from the polarized FEFF calculations, are correct. An alternative
>> would be to manually calculate 3cos^2(θ) for all the paths, but I'm not
>> sure how to calculate it for multiple scattering paths.
>>
>> One note, I am running the FEFF calculation with Larix to get the
>> importance values (labeled as "amp ratio" in the list.dat file, in the FEFF
>> output folder). I wonder if the default settings for getting these
>> amp ratios are not accurate enough for my purposes. It would be nice if I
>> could just pull out the 3cos^2(θ) terms from the FEFF calculations...
>>
>> Anyways, thank you very much for reading this rather lengthy question.
>> Hope it makes sense, and I would appreciate any help regarding this.
>>
>> Best,
>> Soyoung
>>
>> ___
>> Ifeffit mailing list
>> Ifeffit@millenia.cars.aps.anl.gov
>> https://urldefense.us/v3/__http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit__;!!G_uCfscf7eWS!bp762sgHZFb8s_X_nBC2QIvU2vbLrwwQ3V_Q-kmkDrnBTh1_dEUigCCBOfWzwQOITapKqFxLDaSgKD0lJnfnjC9raF_9HcgeAGpLBeE$
>>  
>> <https://urldefense.us/v3/__http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit__;!!G_uCfscf7eWS!d3iaM0LaHguTzEgY-JflrB_EKy_WaT_QTp-L6dyI90ixV9v_NIR02yqPQ5PadVV3-LmO1G3eYHcbOOPbOQ9Ej2b2w5rP6g$>
>> Unsubscribe: 
>> https://urldefense.us/v3/__http://millenia.cars.aps.anl.gov/mailman/options/ifeffit__;!!G_uCfscf7eWS!bp762sgHZFb8s_X_nBC2QIvU2vbLrwwQ3V_Q-kmkDrnBTh1_dEUigCCBOfWzwQOITapKqFxLDaSgKD0lJnfnjC9raF_9HcgeLEtaUm0$
>>  
>> <https://urldefense.us/v3/__http://millenia.cars.aps.anl.gov/mailman/options/ifeffit__;!!G_uCfscf7eWS!d3iaM0LaHguTzEgY-JflrB_EKy_WaT_QTp-L6dyI90ixV9v_NIR02yqPQ5PadVV3-LmO1G3eYHcbOOPbOQ9Ej2aG7EGo-g$>
>>
> ___
> Ifeffit mailing list
> Ifeffit@millenia.cars.aps.anl.gov
> https://urldefense.us/v3/__http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit__;!!G_uCfscf7eWS!bp762sgHZFb8s_X_nBC2QIvU2vbLrwwQ3V_Q-kmkDrnBTh1_dEUigCCBOfWzwQOITapKqFxLDaSgKD0lJnfnjC9raF_9HcgeAGpLBeE$
>  
> Unsubscribe: 
> https://urldefense.us/v3/__http://millenia.cars.aps.anl.gov/mailman/options/ifeffit__;!!G_uCfscf7eWS!bp762sgHZFb8s_X_nBC2QIvU2vbLrwwQ3V_Q-kmkDrnBTh1_dEUigCCBOfWzwQOITapKqFxLDaSgKD0lJnfnjC9raF_9HcgeLEtaUm0$
>  
>


-- 
--Matt Newville  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Larch version up problem

[Matt Newville]

Hi Eun-Suk,

Did you do
   python -m pip install
https://millenia.cars.aps.anl.gov/xraylarch/downloads/xraylarch-latest-py3-none-any.whl

?
That will install the development version (later than 0.9.74, not yet
0.9.75, sorry for that delay).  This works for me:

  from larch.xafs import feffpath
  p1 = feffpath('feff0001.dat', e0=-1, sigma2=0.010)
  p1.s02 = 0.95
  dat = ff2chi([p1])

I don't know of any multiprocessing problem...

Cheers,

On Tue, Feb 6, 2024 at 11:05 PM 정은석  wrote:
>
> Hello  Matt.
>
> I think that you need some time to fix the 'multi-processing problem of 0. 
> 9.74'. If you take a little long time to fix it, can you send me xraylarch 
> version 0.9.71? or could you inform me of the site of the old version?
> I will reinstall xraylarch with it.
>
> Thank you for your effort and contribution
>
> 2024년 2월 5일 (월) 오후 5:09, 정은석 님이 작성:
>>
>> Hello Matt
>>
>> I changed my original code to simple code for you as below.
>> I found the problem of larch 0.9.74 in multi-processing.
>> You can check it with the below code. How can I fix this problem?
>>
>> 
>> # Multi-processing test 
>> import larch
>> from larch import Group
>> from larch.utils import *
>> from larch.xafs import *
>> from larch.io import *
>>
>> import numpy as np
>> import os
>> import torch.multiprocessing as mp
>>
>> dPath = r'C:\Users\Administrator\Desktop\RL\feffit_error_test'
>> os.chdir(dPath)
>> fname1 = 'feff0001.dat'  # N=1, Reff=1.9 N
>>
>> path1 = feffpath(os.path.join(dPath,'FEFF1', fname1))
>> #
>> path_lists=[path1]
>> path_lists[0].s02=0.86
>> 
>>
>> class Func():
>> def __init__(self, path_lists):
>> self.path_lists=path_lists
>>
>> def step(self):
>> self.path_lists[0].e0, self.path_lists[0].degen, 
>> self.path_lists[0].deltar, self.path_lists[0].sigma2 = [2, 5, 0.001, 0.004]
>> ## Theory path들의 합과 theory FFT
>> theory_sum=Group(label='theory_group_sum')
>> ff2chi(self.path_lists, group=theory_sum)
>> new_state=theory_sum.chi
>> return new_state
>>
>> class TestClass():
>> def __init__(self, path_lists):
>> self.path_lists=path_lists
>>
>> def test(self):
>> func1 = Func(self.path_lists)
>> s=func1.step()
>> 
>>
>> T_func=TestClass(path_lists)
>> F_func=Func(path_lists)
>>
>> if __name__ == '__main__':
>> process_list=[]
>> p_N =mp.Process(target=T_func.test,)
>> p_N.start()
>> process_list.append(p_N)
>> for process in process_list:
>> process.join()
>> ##
>> #Problem##
>>   File 
>> "C:\ProgramData\anaconda3\envs\xraylarch\Lib\multiprocessing\process.py", 
>> line 314, in _bootstrap
>> self.run()
>>   File 
>> "C:\ProgramData\anaconda3\envs\xraylarch\Lib\multiprocessing\process.py", 
>> line 108, in run
>> self._target(*self._args, **self._kwargs)
>>   File 
>> "c:\Users\Administrator\Desktop\RL\feffit_error_test\test-ff2chi-problem.py",
>>  line 40, in test
>> s=func1.step()
>>   
>>   File 
>> "c:\Users\Administrator\Desktop\RL\feffit_error_test\test-ff2chi-problem.py",
>>  line 30, in step
>> ff2chi(self.path_lists, group=theory_sum)
>>   File 
>> "C:\ProgramData\anaconda3\envs\xraylarch\Lib\site-packages\larch\xafs\feffdat.py",
>>  line 658, in ff2chi
>> path.create_path_params(params=params)
>>   File 
>> "C:\ProgramData\anaconda3\envs\xraylarch\Lib\site-packages\larch\xafs\feffdat.py",
>>  line 392, in create_path_params
>> parname = self.pathpar_name(pname)
>>   
>>   File 
>> "C:\ProgramData\anaconda3\envs\xraylarch\Lib\site-packages\larch\xafs\feffdat.py",
>>  line 331, in pathpar_name
>> return f'{parname}_{self.dataset}_{self.hashkey}'
>> 
>> AttributeError: 'FeffPathGroup' object has no attribute 'dataset'
>>
>>
>> 2024년 2월 5일 (월) 오전 4:44, Matt Newville 님이 작성:
>>>
>>> Hi Eun-Suk,
>>>
>>> All the examples wit

Re: [Ifeffit] Larch version up problem

[Matt Newville]

Hi Eun-Suk,

All the examples with ff2chi and running feffit work for me.   I sort
of don't understand how that could happen (a FeffPathGroup does -- or
should -- have a `dataset` attribute).

Can you provide an example that shows the problem?

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Larch version up problem

[Matt Newville]

Hi Eun-Suk,

Sorry for the trouble.  I think this should have worked with 0.9.74,
but I also know that I already changed that section of code to avoid
similar problems.   It should work to do
   python -m pip install
https://millenia.cars.aps.anl.gov/xraylarch/downloads/xraylarch-latest-py3-none-any.whl

I think this is a pretty stable version, but I still have a small list
of things I would like to improve before releasing 0.9.75.  I have not
had a lot of time in January for coding and will be traveling for the
next couple of weeks, but talking about software a lot during that
time ;).

Hope that helps, and thanks for your patience.

On Fri, Feb 2, 2024 at 4:06 PM 정은석  wrote:
>
> Hello~
>
> I used Larch 0.9.71. until now. However, I would like to update larch and I 
> reinstall anaconda and larch.
> I installed Larch 0.9.74. as following installation guide
> I didn't have any problems during the installation process. However, I faced 
> problems during feffit fitting.
> Before, I used feffit fitting in larch 0.9.71., and then I hadn't had any 
> problems.
>
> I only changed larch as new version. What am I doing?
>
> When I run feffit fitting, I have debugs as the below:
> -
>   File "c:\Users\Administrator\Desktop\RL\feffit_error_test\test-feffit.py", 
> line 51, in 
> out = feffit(pars, dset)
>   ^^
>   File 
> "C:\ProgramData\anaconda3\envs\xraylarch\Lib\site-packages\larch\xafs\feffit.py",
>  line 645, in feffit
> ds.prepare_fit(params=params, other_hashkeys=dset_hashkeys)
>   File 
> "C:\ProgramData\anaconda3\envs\xraylarch\Lib\site-packages\larch\xafs\feffit.py",
>  line 374, in prepare_fit
> self._generate_hashkey(other_hashkeys=other_hashkeys)
>   File 
> "C:\ProgramData\anaconda3\envs\xraylarch\Lib\site-packages\larch\xafs\feffit.py",
>  line 291, in _generate_hashkey
> dat = [self.data.ek0, self.data.e0, self.data.rbkg]
>^
> AttributeError: 'Group' object has no attribute 'ek0'
> --
>
>
>
> --
> Best regards,
>
> Ph. D. Eun-Suk Jeong
> X-ray absorption fine structure(EXAFS+XANES)
> Mobile:+82-10-4628-9896
>
>
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411

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

Re: [Ifeffit] Larix Pre-edge Statistics

[Matt Newville]

Hi Ryan,

Yeah, this could be a little richer.   For clarity, the "amplitude"
Parameters will be the area of each peak.   Well, it's the amplitude
factor for the unit-normalized lineshape (Gaussian, Lorentzian, Voigt,
etc), so it will be the area under that curve from -Inf to Inf.
Those Infinities probably have small effects, here anyway ;).

As you say, the centroid of multiple peaks is given, but not the total
area under the sum of non-background peaks.  That would not be too
hard to add.  But it might also fall into the category of "the sorts
of calculations we should allow the user to do after a fit" without
having to bake them all in.

That is, if you open a Larch buffer after a pre-edge peak fit, you
could get the most recent best-fit Parameters from lmfit with:

pars = peakresult.result.params

But also, you can get "uvars" as
   uvars = peakresult.result.uvars

which is a dictionary of name:"ufloat" values for all Parameters
(variables and "constrained values"). These "ufloat" values come from
the `uncertainties` package and include uncertainties that know about
the correlations between the Parameters. You can use these for simple
calculations that will propagate the uncertainties (including
correlations).

As an example, if I do a pre-edge peak fit, with 2 Gaussian peaks
(plus Line+Lorentzian for the background), I might get a good fit and
a resulting report (from the larch buffer, do
`print(peakresult.result.fit_report()`) that looks like this:


[[Model]]
(((Model(lorentzian, prefix='bpeak_') + Model(linear,
prefix='bpoly_')) + Model(gaussian, prefix='gauss1_')) +
Model(gaussian, prefix='gauss2_'))
[[Fit Statistics]]
# fitting method   = leastsq
# function evals   = 355
# data points  = 162
# variables= 11
chi-square = 4.5237e-04
reduced chi-square = 2.9958e-06
Akaike info crit   = -2049.75462
Bayesian info crit = -2015.79106
R-squared  = 0.99953048
[[Variables]]
bpeak_amplitude:   1.82988250 +/- 0.04372160 (2.39%) (init = 2.462209)
bpeak_center:  7118.44625 +/- 0.02812082 (0.00%) (init = 7120.091)
bpeak_sigma:   1.36103880 +/- 0.01273292 (0.94%) (init = 2.121656)
bpeak_fwhm:2.72207761 +/- 0.02546583 (0.94%) ==
'2.000*bpeak_sigma'
bpeak_height:  0.42795967 +/- 0.00701416 (1.64%) ==
'0.3183099*bpeak_amplitude/max(1e-15, bpeak_sigma)'
bpoly_intercept:  -6.37404087 +/- 0.65831626 (10.33%) (init = 2.467005)
bpoly_slope:   8.9825e-04 +/- 9.2664e-05 (10.32%) (init = -0.000347)
gauss1_amplitude:  0.10390560 +/- 0.00363058 (3.49%) (init = 0.14991)
gauss1_center: 7111.52424 +/- 0.02714092 (0.00%) (init = 7112.452)
gauss1_sigma:  0.75932812 +/- 0.02151410 (2.83%) (init = 1.315216)
gauss1_fwhm:   1.78808103 +/- 0.05066183 (2.83%) ==
'2.3548200*gauss1_sigma'
gauss1_height: 0.05459081 +/- 7.8147e-04 (1.43%) ==
'0.3989423*gass1_amplitude/max(1e-15, gauss1_sigma)'
gauss2_amplitude:  0.03945700 +/- 0.00329914 (8.36%) (init = 0.116005)
gauss2_center: 7113.18957 +/- 0.04258439 (0.00%) (init = 7113.403)
gauss2_sigma:  0.57985874 +/- 0.03338641 (5.76%) (init = 0.556759)
gauss2_fwhm:   1.36546297 +/- 0.07861898 (5.76%) ==
'2.3548200*gauss2_sigma'
gauss2_height: 0.02714638 +/- 0.00110204 (4.06%) ==
'0.3989423*gauss2_amplitude/max(1e-15, gauss2_sigma)'
fit_centroid:  7111.98258 +/- 0.01448240 (0.00%) ==
'(gauss1_amplitude*gauss1_center +gauss2_amplitude*gauss2_center
)/(gauss1_amplitude+gauss2_amplitude)'
[[Correlations]] (unreported correlations are < 0.100)
C(bpoly_intercept, bpoly_slope)   = -1.
C(bpeak_amplitude, bpeak_center)  = +0.9722
C(gauss1_amplitude, gauss1_sigma) = +0.9186

C(gauss1_amplitude, gauss2_amplitude) = -0.7900


So there are 2 "gaussN_amplitude" Parameters for the area under each
Gaussian, with a strong negative correlation.If you do

 >>>  uvars = peakresult.result.uvars
 >>>  print(uvars['gauss1_amplitude'], uvars['gauss2_amplitude'])
 >>>  print(uvars['gauss1_amplitude'] + uvars['gauss2_amplitude'])

You'll get the area of the sum of the two Gaussians as

   0.104+/-0.004 0.0395+/-0.0033
   0.1434+/-0.0023

That is, one might expect the uncertainties in 'gauss1_amplitude' and
'gauss2_amplitude' should add in quadrature, but that would
overestimate the uncertainty in the sum by almost ~2x because the
parameters are highly (and negatively) correlated.   The uncertainty
in the reported peak heights and the centroid of the two peaks also
takes the correlations into account.

Such calculations are not too hard to do from the Larch buffer or
Python script, but we might think about how that could be exposed more
flexibly.

I can be persuaded to just add a Parameter "peaks_area" = the sum of
the amplitudes, which would then have this value and uncertainty.
Any suggestions for what should be exposed here?

Cheers,

--Matt


On Thu, Dec 14, 2023 at 10:47 

[Ifeffit] beamline scientist position at NSLS-II beamline XFM

[Matt Newville]

Hi Folks,

The University of Chicago is looking to hire a beamline scientist to be
stationed at the NSLS-II XFM (4-BM) beamline.  Details are at:
https://uchicago.wd5.myworkdayjobs.com/en-US/External/details/Research-Professional_JR24518

--Matt Newville
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Help with Larch install on MacOSX 14 (Sonoma)

[Matt Newville]

Hi Peggy,

Great to hear from you and sorry for the trouble.   If there is a
/Users//xraylarch folder that did get created,
does opening a Terminal and typing

 ~/xraylarch/bin/larch -m

work (I think you are saying that this reports "..no such file or
directory: ...").

If that is the case, maybe the installation did not finish correctly.  If
you are up for trying a few more things at the command line,
you might try

   ~/xraylarch/bin/python -m pip install xraylarch

which might work or at least give some useful error messages.

Cheers,






On Thu, Nov 16, 2023 at 10:23 PM Peggy O'Day  wrote:

> Hi Matt,
>
> I’m trying to install Larch on MacOSX 14 (Sonoma) using the 64 bit binary
> installer (new install, new laptop). It created the xraylarch folder in my
> home folder, and installed the python library there. However, it did not
> create a Larch folder on the desktop (or anywhere else I can find). I tried
> the command from the terminal console ($HOME/xraylarch/bin/larch -m) but
> get the message of no such file or directory.  Not sure what to do next…
>
> Hope all is well and thanks for your help,
> Peggy
>
>
>
>
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Errors when I try to export CSV file

[Matt Newville]

Hi Yi,

Sorry for the trouble. Yes, this has been seen and will be fixed in the
next release - I hope today or tomorrow.

On Sun, Nov 12, 2023 at 10:20 AM Yi Sang  wrote:

> Dear developer,
>
>
>
> I met an error when I try to export my XANES data as CSV file. Below is
> the error message:
>
>
>
> Traceback (most recent calls last): File
> "/Users/yisang/xraylarch/lib/python3.11/site-packages/larch/wxxas/xasgui.py",
> line 684, in onExportCSV groups2csv(savegroups, outfile, x=res.xarray,
> y=res.yarray, TypeError: groups2csv() got an unexpected keyword argument
> '_larch'
>
>
>
> How do you think I should resolve this problem?
>
>
>
> Thanks,
>
> Yi
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@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] upcoming Webinar on Synchrotron for Earth and Environmental Science

[Matt Newville]

Hi Folks,

For the Earth and environmental scientists on the list, there will be a
webinar introducing the newly formed  "Synchrotron for Earth and
Environmental Science" on Tuesday, November 14th, at 3 PM Chicago time, as
presented by SEES Director Andy Campbell.  If you are interested in
learning more, you can sign up for the Zoom link for the webinar at:

https://cars.uchicago.edu/sees/2023/09/27/sees-webinar-sees-the-light/

For a little more background:  SEES (Synchrotron Earth and Environmental
Science) is a new cooperative agreement with NSF to manage and enhance NSF
Earth Science-supported beamline operations for Earth and environmental
science research at four DOE synchrotron facilities: the Advanced Photon
Source (APS), the Advanced Light Source (ALS), the National Synchrotron
Light Source II (NSLS-II), and the Stanford Synchrotron Radiation
Lightsource (SSRL).  See https://cars.uchicago.edu/sees/ for more
information.

SEES will support many beamlines across the US for Earth and environmental
science, including a few X-ray microprobe beamlines for XAS and other
spectroscopy and imaging experiments such as the one I run at the APS.
This new organization will also be the source of most of my support for the
foreseeable future, with a healthy fraction of that explicitly earmarked
for work on cyber-infrastructure, including the XAFS-related software
discussed here.

Cheers,

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Differences between Larch and Artemis when performing FEFF calculations

[Matt Newville]

Hi Ava,

OK, thanks - that sounds good.

On Wed, Oct 18, 2023 at 12:12 AM Ava Rajh  wrote:

> Hello Matt!
>
> thank you for the response. In putting together all the project files
> for the minimal working example I tested a bunch more .cif files of
> various materials including different graphite file, and there was no
> difference in Larch and Athena in any of them (as long as the same FEFF
> version and input settings are used) as expected.
>
> Looking closely at the feff input file for the C.cif I was having
> trouble with, there were some differences which I haven't noticed when
> looking through them before. So as far as I am concerned, this was a
> user error on my part, as the generated input files weren't exactly the
> same. If I save the input feff file from Larch and use that in Artemis
> or the other way around, as you suggested, the results match exactly.
> The compared spectra in my previous message were calculated separately,
> exported and plotted together.
>
> thank you for very much for the help and kind regards, Ava
>
>
>
> > Message: 1
> > Date: Mon, 16 Oct 2023 15:24:26 -0500
> > From: Matt Newville 
> > To: XAFS Analysis using Ifeffit 
> > Subject: Re: [Ifeffit] Differences between Larch and Artemis when
> >   performing FEFF calculations
> > Message-ID:
> >   <
> ca+7esbrwm5uobygglmi+-wzru6mn4y_-z1obvg57pau4rsx...@mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Hi Ava,
> >
> > I think you'll have to give us more details about what you have done.
> > The
> > figures you show are all in R-space, so after at least some
> > processing...
> >  So, yes, project files and/or scripts would be helpful.  Yes, there
> > can be
> > subtle changes in the background subtraction (and in the normalization
> > process too) between Larch and Ifeffit/Athena/Artemis.
> >
> > By default, Artemis uses Feff 6.10 and Larch uses Feff 8.  For the C K
> > edge, that could have a noticeable difference, especially in the
> > placing of
> > the k=0 value, though I do not know how big that effect would be for C
> > (graphite?).   But also, Artemis and Larch can both read the inputs
> > from
> > the other calculations:  it might be that this is what you have done to
> > make the plots, but that wasn't 100% clear to me.
> >
> >
> >
> >
> > On Mon, Oct 16, 2023 at 2:08?PM Ava Rajh  wrote:
> >
> >> Dear all!
> >>
> >> I haven't been able to find a similar question/issue in the previous
> >> threads, so I hope someone can help me figure out what is going on.
> >>
> >> I am trying to fit a Carbon EXAFS spectra, using graphite as a model.
> >> I
> >> am first focusing on just the first two single scattering paths, so I
> >> calculated the theoretical paths with FEFF in Larch and tried using
> >> them
> >> to fit the spectra. I was consistently getting slightly lower
> >> distances
> >> than expected, but otherwise an OK fit.
> >>
> >> The issue is, I tried to compare the analysis with a colleague who is
> >> using Athena. At first glance the EXAFS spectra, using the exact same
> >> parameters, looked very similar (but not exactly the exactly the same,
> >> this I attributed to Larch using a different autobk procedure). I
> >> would
> >> have however expected the theoretical paths to match exactly, if they
> >> were calculated and plotted with the same parameters. But they were
> >> also
> >> slightly different.  I then downloaded Athena and spent time trying to
> >> find where the differences come from. If I compare the first two
> >> calculated shells from Larch with the ones from Athena, with exactly
> >> the
> >> same set of test parameters (S02 = 1, E0 = 0, dr1 = 0, s2_1 = 0, dr2 =
> >> 0, s2_2 = 0), the resulting models do not match. I made sure the paths
> >> are calculated from the came .cif file in both cases, use FEFF6, have
> >> the same calculated reference distances, same FT...
> >>
> >> So, my main question is, am I missing something important in regards
> >> to
> >> calculations, why would the calculated paths be different and which
> >> one
> >> would be the "correct" one to use for the fit? And the other question
> >> would be about the fact that EXAFS spectra of experimental data look
> >> slightly different using Larch and Athena, am I right in disregarding
> >> this, or should I dig deeper and find the source of discrepancy?
> &

Re: [Ifeffit] EXAFS fitting - Reff command not recognized

[Matt Newville]

Hi Siebe,

On Tue, Oct 17, 2023 at 8:16 AM van der Veer, Siebe 
wrote:

> Hi all,
>
> I'm having an issue where I want to use a * reff (also tried a*reff, a *
> Reff, a*Reff) as the expression for delta R, but instead of recognizing the
> command Reff, Larix now considers this a parameter it should fit, whereas
> in the past it would just use the value for Reff contained in the path in
> question.
>
> Is anyone else experiencing this issue as well and if so, how can I fix
> this?
>
>
Very, sorry for the trouble.  Yes, I am seeing this too:  entering "alpha *
reff" for a deltaR Path Parameter is incorrectly deciding that both "alpha"
and "reff" should be variables.  I'll investigate why that changed, and fix
it.

In the meantime, it also works to go to Edit Parameters and just remove
"reff" from the list of Parameters.  The fit will still work, as the "magic
reff" value is actually set for each path during the fit.

Thanks,

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Differences between Larch and Artemis when performing FEFF calculations

[Matt Newville]

Hi Ava,

I think you'll have to give us more details about what you have done.  The
figures you show are all in R-space, so after at least some processing...
 So, yes, project files and/or scripts would be helpful.  Yes, there can be
subtle changes in the background subtraction (and in the normalization
process too) between Larch and Ifeffit/Athena/Artemis.

By default, Artemis uses Feff 6.10 and Larch uses Feff 8.  For the C K
edge, that could have a noticeable difference, especially in the placing of
the k=0 value, though I do not know how big that effect would be for C
(graphite?).   But also, Artemis and Larch can both read the inputs from
the other calculations:  it might be that this is what you have done to
make the plots, but that wasn't 100% clear to me.




On Mon, Oct 16, 2023 at 2:08 PM Ava Rajh  wrote:

> Dear all!
>
> I haven't been able to find a similar question/issue in the previous
> threads, so I hope someone can help me figure out what is going on.
>
> I am trying to fit a Carbon EXAFS spectra, using graphite as a model. I
> am first focusing on just the first two single scattering paths, so I
> calculated the theoretical paths with FEFF in Larch and tried using them
> to fit the spectra. I was consistently getting slightly lower distances
> than expected, but otherwise an OK fit.
>
> The issue is, I tried to compare the analysis with a colleague who is
> using Athena. At first glance the EXAFS spectra, using the exact same
> parameters, looked very similar (but not exactly the exactly the same,
> this I attributed to Larch using a different autobk procedure). I would
> have however expected the theoretical paths to match exactly, if they
> were calculated and plotted with the same parameters. But they were also
> slightly different.  I then downloaded Athena and spent time trying to
> find where the differences come from. If I compare the first two
> calculated shells from Larch with the ones from Athena, with exactly the
> same set of test parameters (S02 = 1, E0 = 0, dr1 = 0, s2_1 = 0, dr2 =
> 0, s2_2 = 0), the resulting models do not match. I made sure the paths
> are calculated from the came .cif file in both cases, use FEFF6, have
> the same calculated reference distances, same FT...
>
> So, my main question is, am I missing something important in regards to
> calculations, why would the calculated paths be different and which one
> would be the "correct" one to use for the fit? And the other question
> would be about the fact that EXAFS spectra of experimental data look
> slightly different using Larch and Athena, am I right in disregarding
> this, or should I dig deeper and find the source of discrepancy?
>
> I am enclosing a plot of just the calculated first two shells from
> Athena and Larch (FT: kmin =  2, kmax = 7.5, Fittting in R space, kw =
> 3, kWindow = Hanning, dk = 1.0, Rmin = 0.6, Rmax = 2.1) along with the
> cif file I ended up using for testing the differences. If it would be
> helpful, I can also provide the project files and larch script I used
> for the dataset, but I am mainly interested in understanding the
> differences seen in the theoretical parts first. I tested this using
> Larch v 0.9.72 and Demeter 0.9.26
>
> Thank you ver much for the help, and If I need to provide any additional
> info please let me know.
> kind regards, Ava
>
> --
> Ava Rajh___
> Ifeffit mailing list
> Ifeffit@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
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Fitting mechanism of Artemis

[Matt Newville]

Hi Konstantin,



On Fri, Oct 6, 2023 at 3:11 AM  wrote:

> Dear all,
> I have a general question regarding the mechanism employed in the fitting
> procedures implemented in Artemis.
> How exactly is performed a fit?



That is a pretty open-ended question to be able to answer with precision.
Is the question more about how fitting works in general, or about what is
modeled and allowed to change in the mode for EXAFS?

There are plenty of writeups and resources on both topics, including
program documentation.

Do we have a fixed central atom (absorbing/emitting atom) and only the
> distances to the
> neighbors included in the probed pathways are varied, i.e. by varying the
> coordinates of the corresponding neighbor atoms, or during
> the fitting process Artemis can vary the position of the absorption center
> too?



Within the context of the software here, the answer is sort of that the
central atom is fixed.

The way we model EXAFS is effectively (more below,  as some might object to
this) as a 1-dimensional problem.  Single scattering EXAFS depends only on
the scalar distance between the atoms (or path length for the
photo-electron).  Now, some aspects of EXAFS scattering definitely depend
on more than just distance.  The Z of the scattering atom definitely has a
large effect. The angle of the X-ray polarization vector with the
three-dimensional bond direction can also have an effect.   These are
folded into the scattering amplitude and phase shift.   But even the
disorder terms, sigma^2, and so on, are really capturing the disorder in R,
not the 3-D disorder.

For sure, multiple-scattering paths will have 3D information baked into
them. With Feff and the way we use it, this 3D info *is* folded into the
scattering amplitudes and phase shifts calculated for a path and all we
really vary is the distribution of path lengths for those paths.

In 1-D, it does not matter whether the absorber or scatterer moves, the
only thing that matters is the distance.  In fact, to the extent that
neighboring atoms move together in the same direction, there is no effect
on the EXAFS -- an atom in a solution or melt will have EXAFS (it might be
weak, but it does not fall to 0 at a phase transition).  EXAFS is much more
sensitive to "optical phonons" (neighboring atoms moving in opposite
direction) than to "acoustic phonons" (neighboring atoms moving in the same
direction).

Now, one can take a reverse-monte-carlo approach: calculate a lot of
different local structures, sum the EXAFS for each calculation, and see
which is best.   One can also do something sort of in-between:  calculate a
set of "undistorted paths" and one or more sets of "distorted paths" and
then do a linear (or for some multiple-scattering case, quadratic) model to
combine these.


Could the procedure be constrained in such a way that the scattering
> pathways are adjusted by only varying the coordinates of the central atom?
>

Yes. In fact, this has been done several times.  If you imagine a metal ion
(let's say Ti) surrounded by six neighbors (let's say O) in an octahedron,
a common thing to try to model is if that Ti atom moves away from the
center of the octahedron, say in a perovskite-like structure.

For the simplest case (ie, what I would start with ;)), you could calculate
the EXAFS with Ti at the center of a perfect octahedron and get 6
equivalent paths, and add those to give the EXAFS.  If the octahedron is
distorted, you might have 2, 3, 4, or 6 paths.  Let's go all the way to
"general" 6 paths.   Each path would use a different Feff calculation (or a
copy).  You would not be limited to varying the change in each of the six
path lengths (our 'delr' parameter) to have the same delr for all paths.
Instead, you could define 3 new fitting variables, let's say "dx", "dy",
and "dz" for the displacement of the absorbing Ti from the position used in
the Feff calculation (let's just call that "origin").

If you only have "dz", then one path gets shorter by dz, one gets longer by
dz, and the other four get longer by sqrt(reff*2 + dz**2), where "reff" is
the magic "R used for each path Feff calculation.   I'll leave the more
general case for you ;).

Hope that gets you started,

--Matt
___
Ifeffit mailing list
Ifeffit@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] Larch 0.9.72

[Matt Newville]

Hi Folks,

It's been a few months since the last release, but Larch 0.9.72 is now
available.
There have been several fixes and a few new features.

The XAS analysis GUI application has been renamed from the rather dull name
of "XAS Viewer" to "Larix" (the genus of trees for the Larch family).

We (well, mostly Mauro Rovezzi and others at ESRF) put in a lot of effort
over the summer to generate FDMNES inputs from structural information (CIF
files, structural information from the Materials Project).  This effort to
convert structure information to input files for  Feff, FDMNES, etc. has
been evolving over the past several months, and there will probably be more
done on this in the coming months.  If you are interested in getting
involved, let us know.

There are new binary installer scripts for Windows, MacOS, and even Linux,
and the "GetLarch" scripts have been updated too.  These all will now
install a Python 3.11 environment.  Although installation is not fast, it
is somewhat faster than it has been in the past due to using the Mamba
variation of the Anaconda Python tools.

More release notes are at
https://github.com/xraypy/xraylarch/releases/tag/0.9.72

If you have a fairly recent version of Larch installed, you should be
informed that a new version is available, and be prompted to install or run
the Larch Updater script.

Let us know if you have any troubles with this version or questions,
comments, or suggestions for improvements!

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] sulfur XAS for Li2SO3

[Matt Newville]

Hi Enyuan,

Sorry, I don't have a spectrum on that compound, and I don't see one at
https://www.esrf.fr/home/UsersAndScience/Experiments/XNP/ID21/php/Database-SCompounds.html
either.

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Larch and calculation of theoretical EXAFS via cif -files part 2

[Matt Newville]

Hi Stefan,

Hmm, it looks like the pymatgen CIF parser is having a hard time with that
file.
I'll investigate...

On Mon, Aug 14, 2023 at 10:12 AM Mangold, Stefan (IPS) <
stefan.mang...@kit.edu> wrote:

> Dear all,
>
> i have another set of cif files, which also don't work on larch. They work
> with Artemis, except that they hit the 500 atoms limit per cluster. This
> won't be a problem in larch, because of the option to exclude the H-atoms.
>
> One problem seems to occur on the line
>
> _chemical_formula_moiety
> ;
> 2(C18 H36 K1 N2 O6 1+),Bi2 2-
> ;
>
> which I rewrote to
>
> _chemical_formula_moiety '2(C18 H36 K1 N2 O6 1+),Bi2 2-'
>
>
> but still I got the message
>
> Error reading CIF File:
> /Users/stefanmangold/Documents/eigene_Daten/Messdaten/PrepMessungen/XPS-Proben/Bi2-crypt-222_e.cif
> Traceback (most recent calls last):
>   File
> "/Users/stefanmangold/xraylarch/lib/python3.10/site-packages/larch/wxlib/cif_browser.py",
> line 618, in onImportCIF
> cif_data = parse_cif_file(path)
>   File
> "/Users/stefanmangold/xraylarch/lib/python3.10/site-packages/larch/xrd/amcsd.py",
> line 142, in parse_cif_file
> raise ValueError(f'Cannot read symmetries from file {filename:s}')
> ValueError: Cannot read symmetries from file
> /Users/stefanmangold/Documents/eigene_Daten/Messdaten/PrepMessungen/XPS-Proben/Bi2-crypt-222_e.cif
>
>
> Anybody an idea, I attached the unchanged file (Bi2-crypt-222.cif) and the
> edited file (Bi2-crypt-222_e.cif). Any idea what’s wrong?
>
>
>
>
> best regards
>
> Stefan
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Larch and calculation of theoretical EXAFS via cif -files

[Matt Newville]

Hi Stefan,

OK, yes I see that too.  I have this fixed in the code.  For a quick
workaround, changing

_chemical_name_common 'Bismuth potassium (2/1)'

to

_chemical_name_common 'Bismuth potassium'

will fix the problem.


On Wed, Aug 9, 2023 at 11:25 AM Mangold, Stefan (IPS) <
stefan.mang...@kit.edu> wrote:

>
>
>
> Am 09.08.2023 um 17:17 schrieb Matt Newville :
>
> Hi Stefan,
>
> Can you send a CIF file that is not working? I tried the one for BiK3 from
> the built-in AmMin database, and it worked for me.  But, for sure it is
> possible to come up with a CIF file that doesn't work!  They are
> surprisingly tricky.
>
> On Wed, Aug 9, 2023 at 9:51 AM Mangold, Stefan (IPS) <
> stefan.mang...@kit.edu> wrote:
>
> Dear all,
>
> i have some cif files, which doesn’t work on larch. One example is KBi2,
> which works well on Artmenis with feff6. The same file (and also the cifs
> found in the database) won't work on larch (not with feff 6 nor feff8).
> There is no error message displayed -> just, that feff is started.
>
> 
> ###
> # Run Feff in folder:
> /Users/Name/.larch/feff/Bi1_L3_Bismuth_potassium__2_1__cif200012_13
> ###
> ###
>
> no result even after hours.
>
> Any ideas?
>
> Best regards
>
> Stefan
>
>
>
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Larch and calculation of theoretical EXAFS via cif -files

[Matt Newville]

Hi Stefan,

Can you send a CIF file that is not working? I tried the one for BiK3 from
the built-in AmMin database, and it worked for me.  But, for sure it is
possible to come up with a CIF file that doesn't work!  They are
surprisingly tricky.

On Wed, Aug 9, 2023 at 9:51 AM Mangold, Stefan (IPS) 
wrote:

> Dear all,
>
> i have some cif files, which doesn’t work on larch. One example is KBi2,
> which works well on Artmenis with feff6. The same file (and also the cifs
> found in the database) won't work on larch (not with feff 6 nor feff8).
> There is no error message displayed -> just, that feff is started.
>
> 
> ###
> # Run Feff in folder:
> /Users/Name/.larch/feff/Bi1_L3_Bismuth_potassium__2_1__cif200012_13
> ###
> ###
>
> no result even after hours.
>
> Any ideas?
>
> Best regards
>
> Stefan
>
>
>
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] request for comments on XDI and NeXuS data formatting

[Matt Newville]

Hi John,


>  The improved NeXuS format for XAS data looks fine to me. Good idea.  But
it makes me wonder whether
> a similar formatting for theoretical XAS data would be useful, especially
for analysis purposes.

Thanks.  That is an interesting question. I don't have an immediate answer.

I think it is not too difficult to read the plain text output files from
FEFF and FDMNES.  I don't have much experience withther codes.  That is, I
expect that plain text files with a few labeled columns is probably good
enough for "energy" and "calculated mu".  I am not at all sure if there
could be common ways to label the other parts of the calculation like
broadening terms or partial DOS, etc.   And, it would be great to be able
to extend any conventions to resonant emission/absorption data like RIXS
plane or q-dependent X-ray Raman.

But it would be worth discussing this, maybe with other theorists, people
doing multiple XANES+DFT++ calculations, and maybe people from the
Materials Project.

The situation for experimental data is sort of worse, even for beamlines
that mostly collect XAFS and at well-run facilities. Beamline "raw data
files" might have 100 columns, and will often vary beamline-by-beamline and
sometimes month-to-month.  For transmission data, it is often easy to guess
how to build mu(E), but for fluorescence data, it is often very hard to
know what "the data" is.   It's OK if the people using the data know what
to do and then publish the reduced data.   But as we move (some faster than
others) toward being required to make all data available, this is becoming
a problem.

But, yes, we want to keep in mind that "experimental plain XAFS data"
should not be the only goal.


On Mon, Aug 7, 2023 at 12:44 PM John J Rehr  wrote:

> Hi Matt et al.
>
>   The improved NeXuS format for XAS data looks fine  to me. Good idea.
> But it makes me wonder whether
> a similar formatting  for theoretical XAS data would be useful, especially
> for analysis purposes.
>
>   Cheers,
>   John
>
>   Cheers,
>   John
>
> On Sun, Aug 6, 2023 at 11:45 PM Matt Newville 
> wrote:
>
>> Hi Folks,
>>
>> As some of you are aware, there is a Q2XAFS meeting in a few weeks. I
>> will be presenting some work on using NeXuS and HDF5 to store and
>> distribute XAS data.  This builds on and closely follows the XDI format
>> from Bruce Ravel.
>>
>> While XDI is a great way to represent a single XAS spectrum, it is not
>> able to contain multiple spectra.  It also is not very specific about how
>> to deal with data files with a large number (say, > 20) columns as might be
>> found coming from many beamlines with multi-element detectors.   I think
>> that many of us are starting to see the need to regularly provide "raw" or
>> "nearly raw" data as supplementary data for published articles or as part
>> of datasets made available under FAIR data principles.   While XDI could be
>> one way to do that, I think it is also reasonable to reconsider formats
>> other than plaintext files holding one spectrum.
>>
>> As I am preparing to present this, I've put together something like a
>> blog post on a proof-of-concept for a NeXuS file format based on XDI at
>> https://millenia.cars.aps.anl.gov/nxxas/
>> <https://urldefense.com/v3/__https://millenia.cars.aps.anl.gov/nxxas/__;!!K-Hz7m0Vt54!kMFKt35rA0N6RTvxlblky6bO9JXBO8OrG0-1fASPtZRZgMioM0kN4pXZ8yciGaDW8EP7Ap43KgPKx1WyX9Np-g$>.
>> There are a few example data files using the proposed layout at
>> https://millenia.cars.aps.anl.gov/nxxas/nexus_xas.html
>> <https://urldefense.com/v3/__https://millenia.cars.aps.anl.gov/nxxas/nexus_xas.html__;!!K-Hz7m0Vt54!kMFKt35rA0N6RTvxlblky6bO9JXBO8OrG0-1fASPtZRZgMioM0kN4pXZ8yciGaDW8EP7Ap43KgPKx1V12lXMVw$>.
>> There is also a Pull Request in with the NeXuS developers for this.
>>
>> If you are interested and have time over the next week or two, please
>> read the pages above and let me know your thoughts on this.  I know that
>> not everyone is interested in this, but I also know that some who might be
>> interested are not able to attend Q2XAFS.  I think the discussion on this
>> topic should be as wide as possible, which is why I am posting this here
>> and before the meeting.
>>
>> Thanks,
>>
>> --Matt Newville > <https://urldefense.com/v3/__http://cars.uchicago.edu__;!!K-Hz7m0Vt54!kMFKt35rA0N6RTvxlblky6bO9JXBO8OrG0-1fASPtZRZgMioM0kN4pXZ8yciGaDW8EP7Ap43KgPKx1WDPX86OA$>
>> >
>>
>> ___
>> Ifeffit mailing list
>> Ifeffit@millenia.cars.aps.anl.gov
>>
>> https://urldefense.com/v3/__http://millenia.cars.aps.anl.gov/mailman/listi

[Ifeffit] request for comments on XDI and NeXuS data formatting

[Matt Newville]

Hi Folks,

As some of you are aware, there is a Q2XAFS meeting in a few weeks. I will
be presenting some work on using NeXuS and HDF5 to store and distribute XAS
data.  This builds on and closely follows the XDI format from Bruce Ravel.


While XDI is a great way to represent a single XAS spectrum, it is not able
to contain multiple spectra.  It also is not very specific about how to
deal with data files with a large number (say, > 20) columns as might be
found coming from many beamlines with multi-element detectors.   I think
that many of us are starting to see the need to regularly provide "raw" or
"nearly raw" data as supplementary data for published articles or as part
of datasets made available under FAIR data principles.   While XDI could be
one way to do that, I think it is also reasonable to reconsider formats
other than plaintext files holding one spectrum.

As I am preparing to present this, I've put together something like a blog
post on a proof-of-concept for a NeXuS file format based on XDI at
https://millenia.cars.aps.anl.gov/nxxas/.  There are a few example data
files using the proposed layout at
https://millenia.cars.aps.anl.gov/nxxas/nexus_xas.html.  There is also a
Pull Request in with the NeXuS developers for this.

If you are interested and have time over the next week or two, please read
the pages above and let me know your thoughts on this.  I know that not
everyone is interested in this, but I also know that some who might be
interested are not able to attend Q2XAFS.  I think the discussion on this
topic should be as wide as possible, which is why I am posting this here
and before the meeting.

Thanks,

--Matt Newville 
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Help installing Demeter on a Mac

[Matt Newville]

ng Demeter on a Mac*
> *Date: *June 30, 2023 at 10:02:03 AM MDT
> *To: *"ifeffit@millenia.cars.aps.anl.gov" <
> ifeffit@millenia.cars.aps.anl.gov>
>
>
> Hello All,
> I’m a new postdoc at NREL, trying to install Demeter on my NREL Mac. I
> have previously only installed it on a Linux system. I followed the
> instructions
> <https://bruceravel.github.io/demeter/documents/SinglePage/macinstallation.html>
>  for installing on a Mac, including the logout/login, and the
> installation appeared to be successful, with no errors. However, when I
> then try to run athena/artemis/hephaestus from the command line, I get a
> ‘command not found’ error.  Has anyone encountered this problem before? I
> thought I found a thread in the archives from 2014, but there was not
> response to the issue. I suspect it may be that the command location was
> not added to the $PATH, but am not sure where it is in order to add it.
> Here’s the output from echo $PATH:
>
> /opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin
> Any help would be appreciated!
> Thanks,
> Kyle
>
>
>
> ___
> Ifeffit mailing list
> Ifeffit@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@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Brain teaser

[Matt Newville]

Hi Anatoly,

I think Robert or Matthew made this point, but if set up for Pd, the mirror
angle may have been chosen to reject ~70 keV, but possibly not 36 keV --
the harmonic at the Au edge.  Do you know what the mirror angle was?

The Ar-filled I0 would be very efficient at absorbing 12 keV, and only
pretty efficient at absorbing 36 keV.   That would leave a more
harmonic-rich beam exiting I0 and hitting the sample than entering I0.  The
good news is that the dense Pd/Au sample would be efficient at absorbing 36
keV too (but it was ~1 absorption length at 24 keV?) too.

Mono reflectivity of 36 keV vs 12 keV might also factor in.  If you were
not deliberately detuning but the crystals were slightly misaligned,  the
harmonic content may change significantly over the scan range.   I would
not guess that to dominate, but maybe it factors in.


On Thu, Jun 15, 2023 at 9:54 AM Anatoly Frenkel <
anatoly.fren...@stonybrook.edu> wrote:

> Thank you, Matt.
> Ion chambers were filled with 90% Ar, and Pt coating was used, because we
> were measuring Pd K edge for the project, but we decided to look at the Au
> edge for testing purposes.
>
> Anatoly
>
> On Jun 15, 2023, at 10:45 AM, Matt Newville 
> wrote:
>
> 
> I'm not sure why the intensity would go up unless the ion chamber was
> poorly set up.   But, as others have pointed out, the mirror reflectivity
> for a Pt mirror should not change significantly over this energy range -
> the energy range is not that close to the Pt L3 or L2 edges.Depending
> on where it was located, fluorescence from the Pt mirror might pollute the
> signal in the I0 ion chamber, but that would also likely be a fairly
> constant background.
>
> But, why would you fill the I0 ion chamber with Argon?  A 10-cm ion
> chamber filled with Ar would absorb about 50% of the beam at 12 keV.   Even
> at 24 keV, that would absorb 8% of the beam - not necessarily a problem but
> also probably generating at least a micro-Amp, so way more signal than you
> would need.
>
> For mirror reflectivity curves, allow me to humbly remind everyone of
>
> https://xraydb.xrayabsorption.org/reflectivity/Pt/21.45/2.5/10/s/1000/51000/50/platinum/linear
>
> which is both interactive and works with X-ray energies above 30 keV.
>
>
> On Wed, Jun 14, 2023 at 7:28 PM Anatoly Frenkel <
> anatoly.fren...@stonybrook.edu> wrote:
>
>> Hello, all. It is a low- to medium- level brain teaser.
>>
>> Pt-coated collimating mirror was in place for Pd K-edge measurement, but
>> Au L3-edge of Pd-Au alloy was measured (for testing purposes). I0 and It
>> detectors were both Ar filled ionization chambers. Because of the energy
>> dependence of reflectivity of the Pt mirror, I0 intensity was strongly
>> nonlinear (blue curve). However, the transmission intensity in the It
>> detector was almost linear (red curve). Why?
>>
>> Anatoly
>>
>> 
>>
>> ___
>> Ifeffit mailing list
>> Ifeffit@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  630-327-7411
> ___
> Ifeffit mailing list
> Ifeffit@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@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Brain teaser

[Matt Newville]

I'm not sure why the intensity would go up unless the ion chamber was
poorly set up.   But, as others have pointed out, the mirror reflectivity
for a Pt mirror should not change significantly over this energy range -
the energy range is not that close to the Pt L3 or L2 edges.Depending
on where it was located, fluorescence from the Pt mirror might pollute the
signal in the I0 ion chamber, but that would also likely be a fairly
constant background.

But, why would you fill the I0 ion chamber with Argon?  A 10-cm ion chamber
filled with Ar would absorb about 50% of the beam at 12 keV.   Even at 24
keV, that would absorb 8% of the beam - not necessarily a problem but also
probably generating at least a micro-Amp, so way more signal than you would
need.

For mirror reflectivity curves, allow me to humbly remind everyone of

https://xraydb.xrayabsorption.org/reflectivity/Pt/21.45/2.5/10/s/1000/51000/50/platinum/linear

which is both interactive and works with X-ray energies above 30 keV.


On Wed, Jun 14, 2023 at 7:28 PM Anatoly Frenkel <
anatoly.fren...@stonybrook.edu> wrote:

> Hello, all. It is a low- to medium- level brain teaser.
>
> Pt-coated collimating mirror was in place for Pd K-edge measurement, but
> Au L3-edge of Pd-Au alloy was measured (for testing purposes). I0 and It
> detectors were both Ar filled ionization chambers. Because of the energy
> dependence of reflectivity of the Pt mirror, I0 intensity was strongly
> nonlinear (blue curve). However, the transmission intensity in the It
> detector was almost linear (red curve). Why?
>
> Anatoly
>
> [image: image.png]
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@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] Larch 0.9.70 released

[Matt Newville]

Hi Folks,

We have been releasing a version of X-ray Larch every few months, steadily
adding features and improving bugs in XAS Viewer and in the general
library.  We have not felt the need to announce every release, but I would
like to address a problem that many people have seen with automated
updates, especially on Windows.

Basically, automated updates from XAS Viewer do not work on Windows, and
running the automated updates can (and I think even "usually will") lead to
a broken installation.
This can be (and needs to be) fixed by running

C:\Users\YourName\xraylarch\Scripts\pip install --upgrade xraylarch

from a Command Prompt terminal.

With the latest version, XAS Viewer will only inform you (in the status
bars at the bottom of the main window) when an update is available, and not
continually prompt you to update now.  A new desktop application called
"Larch Updater" will also be installed that will run the above command.

Unfortunately, the current version you have installed will still prompt you
for an automated update.  I recommend that you do not do this, but run the
above command yourself, and then going forward, we'll all be able to use
the updater at our own pace.

 --Matt

PS: Some of the other changes in the latest version can be seen at
https://github.com/xraypy/xraylarch/releases/tag/0.9.70
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] python accesses outlook PST files during X-ray larch binary installation on Windows 10 computer

[Matt Newville]

Hi Andreas,

Sorry for the trouble.  We are not purposefully trying to launch Outlook -
I would not wish that on anyone! I have seen a similar issue on some
Windows machines in the past, where either the default mail program, such
as Outlook, or web browser, or sometimes the system Calculator would be
launched, possibly in the background, but that might prompt the user to
sign-in or set up the mail/browser system.  When I looked into this (now ~5
years ago), I could get this to happen and narrowed it down to certain
wxPython components, but ones that we do use regularly.

Slightly "in the weeds":  At the suggestion of wxPython developers,  I
added a wrapper around Python opening a process or doing the equivalent of
a Windows "Start" command that would print out a message before doing such
a "start".   In a classic debugging story, adding that wrapper never showed
the actual problem, but also made the problem appear to go away.  I have
not seen this bug in years.  About a year ago, I was doing some "cleanup"
and removed this wrapper.  I have not seen or heard of the problem since.
But, I will add this back.  With that back in place, if you (or anyone
else) sees this happen, please look at the Windows cmd shell for any
messages that might show up and let me know.

I'm hoping to tag and push 0.9.69 out to PyPI today or early tomorrow, and
this will be included.   FWIW, 0.9.69 will be a "beta"-like pre-release and
not yet pushed out as an automatic update, and a more official release of
0.9.70 probably by next Monday.  In fact, one of the problems to solve is
the failure of automatic updates on Windows.  I'll send out more complete
announcements for both of these.


On Mon, Jun 5, 2023 at 9:26 AM Voegelin, Andreas 
wrote:

> Dear All
>
> I apologize for this question related to IT safety rather than science and
> the use of Larch.
>
> Today, I installed Larch for Windows on an institute computer using the
> latest Windows 64-bit binary installer (0.9.68).  Now I got the following
> alert from our IT security:
> “The process c:\users\%USER%\appdata\local\xraylarch\python.exe accessed
> Outlook files.  The user who ran the process was  .  The accessed files
> were: .pst, .pst”.
>
> It seems that during the installation of Larch, python.exe accessed some
> outlook archive files in another folder on the C drive, and I do not know
> if this should be a matter of concern.
> Has anyone experienced a similar behavior before, or does anyone with
> Larch/python skills have an explanation for this?
>
> Cheers, Andreas
>
>
>
>
> ___
> Ifeffit mailing list
> Ifeffit@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@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Problems with FEFF calculation using CIF file

[Matt Newville]

Hi Anouk,

I am not sure what is happening with that CIF file.  When I try to read
that with pymatgen, I get

>>> from pymatgen.io.cif import CifParser
>>> structs = CifParser('VOXZAJ.cif')
>>> structs.get_structures()
.../site-packages/pymatgen/io/cif.py:1145: UserWarning: Error is Species
occupancies sum to more than 1!.
  warnings.warn(f"Error is {str(exc)}.")
.../site-packages/pymatgen/io/cif.py:1148: UserWarning: Issues encountered
while parsing CIF: Some occupancies ([2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2]) sum to > 1! If they are within the
occupancy_tolerance, they will be rescaled. The current occupancy_tolerance
is set to: 1.0
Species occupancies sum to more than 1!
  warnings.warn("Issues encountered while parsing CIF: " +
"\n".join(self.warnings))
Traceback (most recent call last):
  File "", line 1, in 
  .../site-packages/pymatgen/io/cif.py", line 1150, in get_structures
raise ValueError("Invalid cif file with no structures!")
ValueError: Invalid cif file with no structures!

If you remove all the atomic sites that have a "B" in their name, that gets
resolved, but I do not know if that is still the correct structure - or
what the "B" means.

CIF is complicated, but just from a practical point of view, I think we are
going to take `pymatgen` as the arbitrator of "valid CIF".


On Wed, May 24, 2023 at 11:30 AM Volker, Anouk 
wrote:

> Dear all,
>
> I hope this email finds you well. I have encountered a problem that I have
> not been able to fix on my own. I have a specific CIF file  (from the CCDC
> database) that is attached to the e-mail. After removing the duplicate
> atoms in the file, the ATOMS window seems fine. The FEFF calculation will
> run without any errors and within the FEFF window the paths are displayed
> and can be plotted. The problem arises when I try to take some of the paths
> from the FEFF window and drag them into the Path window. Now the paths can
> no longer be plotted and when trying to use them to fit, it seems like the
> paths are non-existent as well.
>
> Is there something wrong with the CIF file that causes this to happen and
> if so, what can be done to fix it? I have already tried to make a feff.inp
> file from the xyz data (after opening the CIF file in any viewer), but this
> gives the same problem.
>
> Thank you in advance,
>
> Kind regards,
> Anouk Volker
>
> Master student, Browne Group
> Stratingh Institute, University of Groningen
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] [Attachment Removed] Re: Low amplitude chi signal of first shell calculated by FEFF

[Matt Newville]

Hi Fan,

If you included an attachment, I did not see it.  If so, can you send it
some other way?

I would not expect that the Sr K-edge of SrTiO3 needs much playing around
with parameters in the feff.inp file prior to running Feff.   I would
advise against doing that unless you know what you are doing.  Don't set Vi
to be below 0.

I would be more inclined to believe that the data treatment had problems or
that the use of the feff paths had problems.   Without knowing what you
did, it is very hard to speculate what might be going wrong.


On Tue, May 23, 2023 at 9:38 PM Dongxiao  wrote:

> An attachment on this email message was removed because it contained
> potentially dangerous content. If you are expecting a file from the sender,
> request that they provide access to it via a file sharing service.
> --
>
> Hello, Matt, cc: who is interested,
>
>
>
> Thank you very much for your reply.
>
> The low amplitude chi signal is common when I calculated the A site EXAFS
> signal of perovskite structure.
>
> Especially the chi signal of first single scattering path (A-O) is
> unreasonable low.
>
> In my case (Sr K-edge EXAFS of SrTiO3), the intensity of calculated chi is
> smaller than the low-temperature experimental chi.
>
> I have been struggling with this problem for some time. I am looking
> forward to somebody who can give me some advice..
>
> I attached the related files for your check.
>
>
>
> I try to vary Vr and Vi value and want to see how the amplitude change.
>
> If set the Vi to negative, it indeed can increase the amplitude, but I
> don’t know if it is proper.
>
> Maybe the problem is caused by the bad muffin-tin potential, but I don’t
> know how to improve it.
>
>
>
> Can you give me some advice?
>
>
>
> Best regards,
>
> Fan
>
>
>
> -Original Message-
>
> Matt Newville
> <https://www.mail-archive.com/search?l=ifeffit@millenia.cars.aps.anl.gov=from:%22Matt+Newville%22>
>  Fri, 12 May 2023 14:25:36 -0700
> <https://www.mail-archive.com/search?l=ifeffit@millenia.cars.aps.anl.gov=date:20230512>
>
>
>
> Hi Fan,
>
>
>
> On Fri, May 12, 2023 at 9:56 AM  wrote:
>
>
>
> > Hi, All
>
> >
>
> >
>
> >
>
> > The problem I meet is the low amplitude chi signal of first shell
>
> > calculated by FEFF.
>
> >
>
> > The consequence of the fitting is large value of SO2 (1.5-2.0), which is
>
> > quite unacceptable.
>
> >
>
> > I tried to fit the dataset measured by different people at different
>
> > beamline, the consequence is same.
>
> >
>
> >
>
> >
>
> > My data is T-dependent Sr K-edge EXAFS of SrTiO3, path file generated by
>
> > FEFF10, fitting process by Larch+python.
>
> >
>
> > By check the email list, it seems the long shell distance (2.7 A) is the
>
> > origin of the problem. I am not sure for that.
>
> >
>
> > I also try to vary the Vi value to improve the amplitude, the change is
>
> > small.
>
> >
>
> > Can any body give me some advice?
>
> >
>
>
>
> I would not expect that a Sr-O distance of 2.7 to 2.8Ang would cause an
>
> amplitude problem.  I would tend to expect that being off by a factor of 2
>
> would
>
> imply normalization issues.You could try to vary Vi, but I would not
>
> guess that you need to do that.  Why do you set Vi to 2 (eV)?
>
>
>
> Do you have data and/or analysis steps (script or Larch session file) you
>
> can share?
>
>
>
> >
>
> >
>
> > Best regards,
>
> >
>
> > Fan
>
> >
>
> >
>
> >
>
> > My feff.inp file is like:
>
> >
>
> > 
>
> >
>
> > * This feff8 file was generated by Demeter 0.9.26
>
> >
>
> > * Demeter written by and copyright (c) Bruce Ravel, 2006-2019
>
> >
>
> > * --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
>
> >
>
> > * space = 221
>
> >
>
> > * a =   3.90500b=   3.90500c =   3.90500
>
> >
>
> > * alpha =  90.0beta =  90.0gamma =  90.0
>
> >
>
> > * rmax  =   9.0core  = Sr
>
> >
>
> > * polarization = 0  0  0
>
> >
>
> > * shift =   0  0  0
>
> >
>
> > * atoms
>
> >
>
> > * # el. x   y   ztag
>
> >
>
> > *   Sr 0.0 0.0 0.0   Sr
>
> >
&

Re: [Ifeffit] Not possible to install larch on actual system and Mac M1 system

[Matt Newville]

Hi Stefan,

OK, glad to hear you got it working, and thanks for the explanation.

It is definitely not the intention that the Xcode developer tools need to
be installed.  I do have those installed, but still `fabio` did install
from a "whl" (packaged binary), not a "tar.gz" (a source code kit) for me.

I think this is probably not related to ARM/M1 v Intel.  I think it is just
whether the binary was expected to be built on the target machine or not.

Anyway, thanks  - that might help someone else who gets stuck too.
Cheers,



On Wed, May 17, 2023 at 4:45 AM Mangold, Stefan (IPS) <
stefan.mang...@kit.edu> wrote:

> Dear all, Dear Matt
>
>
> found the reason:
>
> - you need command line developer tools installed
>
> - these have to be up to date
>
> If this is the case, the install via script works also on ARM Macs ….; the
> Intel-Mac, which I tested, had an updated version installed.
>
> best regards
>
> Stefan
>
> Am 16.05.2023 um 16:31 schrieb Matt Newville :
>
> Hi Stefan,
>
> Sorry for the trouble.  As it turns out, I am writing this on a Macbook M1
> running 13.3.1.
>
> I think the "GetLarch.sh" script should work (downloading
> https://raw.githubusercontent.com/xraypy/xraylarch/master/installers/GetLarch.sh
>
> and running with `sh GetLarch.sh` in a Terminal).
>
> For me, that is using fabio version 2023.4.1.
>
> Does that work for you?  If not, can you send the log file (GetLarch.log)?
>
> --Matt
>
> On Tue, May 16, 2023 at 9:19 AM Mangold, Stefan (IPS) <
> stefan.mang...@kit.edu> wrote:
>
>> Dear all,
>>
>> from binary package:
>> can’t write to system partition
>>
>> by script and by anaconda I got the following message back:
>>
>> Collecting fabio
>>   Using cached fabio-2023.4.1.tar.gz (724 kB)
>>   Installing build dependencies ... done
>>   Getting requirements to build wheel ... done
>>   Preparing metadata (pyproject.toml) ... error
>>   *error*: *subprocess-exited-with-error*
>>
>> System ist 13.3.1, tried to install the newest version completely from
>> scratch, because the update killed my larch version ….
>>
>> best regards
>>
>> Stefan
>> ___
>> Ifeffit mailing list
>> Ifeffit@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@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@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Not possible to install larch on actual system and Mac M1 system

[Matt Newville]

Hi Stefan,

Sorry for the trouble.  As it turns out, I am writing this on a Macbook M1
running 13.3.1.

I think the "GetLarch.sh" script should work (downloading
https://raw.githubusercontent.com/xraypy/xraylarch/master/installers/GetLarch.sh

and running with `sh GetLarch.sh` in a Terminal).

For me, that is using fabio version 2023.4.1.

Does that work for you?  If not, can you send the log file (GetLarch.log)?

--Matt

On Tue, May 16, 2023 at 9:19 AM Mangold, Stefan (IPS) <
stefan.mang...@kit.edu> wrote:

> Dear all,
>
> from binary package:
> can’t write to system partition
>
> by script and by anaconda I got the following message back:
>
> Collecting fabio
>   Using cached fabio-2023.4.1.tar.gz (724 kB)
>   Installing build dependencies ... done
>   Getting requirements to build wheel ... done
>   Preparing metadata (pyproject.toml) ... error
>   *error*: *subprocess-exited-with-error*
>
> System ist 13.3.1, tried to install the newest version completely from
> scratch, because the update killed my larch version ….
>
> best regards
>
> Stefan
> ___
> Ifeffit mailing list
> Ifeffit@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@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Importing the generated paths by FEFF9.6 to Artemis

[Matt Newville]

Hi Esmael,

The feff.dat files generated by Feff9 or 10 for EXAFS (and the correct
PRINT flags -- I believe exactly the same values as for Feff8) should be
usable in Artemis (or Larch/XAS Viewer).  Is that not working for you?


On Tue, May 16, 2023 at 8:51 AM Esmael Balaghi <
esmael.bala...@fit.uni-freiburg.de> wrote:

> Dear All,
>
> Is there any practical way to load the generated paths by FEFF9 (paths.dat
> output file in JFEFF ver. 9.6) into Artemis?
>
> Bests,
>
> Esmael
> ___
> Ifeffit mailing list
> Ifeffit@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
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Low amplitude chi signal of first shell calculated by FEFF

[Matt Newville]

Hi Fan,


On Fri, May 12, 2023 at 9:56 AM  wrote:

> Hi, All
>
>
>
> The problem I meet is the low amplitude chi signal of first shell
> calculated by FEFF.
>
> The consequence of the fitting is large value of SO2 (1.5-2.0), which is
> quite unacceptable.
>
> I tried to fit the dataset measured by different people at different
> beamline, the consequence is same.
>
>
>
> My data is T-dependent Sr K-edge EXAFS of SrTiO3, path file generated by
> FEFF10, fitting process by Larch+python.
>
> By check the email list, it seems the long shell distance (2.7 A) is the
> origin of the problem. I am not sure for that.
>
> I also try to vary the Vi value to improve the amplitude, the change is
> small.
>
> Can any body give me some advice?
>

I would not expect that a Sr-O distance of 2.7 to 2.8Ang would cause an
amplitude problem.  I would tend to expect that being off by a factor of 2
would
imply normalization issues.You could try to vary Vi, but I would not
guess that you need to do that.  Why do you set Vi to 2 (eV)?

Do you have data and/or analysis steps (script or Larch session file) you
can share?

>
>
> Best regards,
>
> Fan
>
>
>
> My feff.inp file is like:
>
> 
>
> * This feff8 file was generated by Demeter 0.9.26
>
> * Demeter written by and copyright (c) Bruce Ravel, 2006-2019
>
> * --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
>
> * space = 221
>
> * a =   3.90500b=   3.90500c =   3.90500
>
> * alpha =  90.0beta =  90.0gamma =  90.0
>
> * rmax  =   9.0core  = Sr
>
> * polarization = 0  0  0
>
> * shift =   0  0  0
>
> * atoms
>
> * # el. x   y   ztag
>
> *   Sr 0.0 0.0 0.0   Sr
>
> *   Ti 0.5 0.5 0.5   Ti
>
> *   O  0.0 0.5 0.5   O
>
> * --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
>
> * --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
>
> *  total mu*x=1:  32.298 microns,  unit edge step:  44.289 microns
>
> *  specific gravity:  5.118
>
> * --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
>
> *  normalization correction:0.00029 ang^2
>
> * --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
>
> *  Sr K edge energy = 16105 eV
>
> EDGE K
>
> S02 1.0
>
>
>
> * potxsph  fms   paths genfmt ff2chi
>
> CONTROL 1 1 1 1 1 1
>
>
>
> PRINT 1 0 0 0 0 3
>
>
>
> * ixc  [ Vr  Vi ] *** ixc=0 means to use Hedin-Lundqvist
>
> EXCHANGE 0 2 1 -1
>
> *** Radius for self-consistent pots (2 shells is a good choice)
>
> * r_scf  [ l_scf   n_scf   ca ]   *** l_scf = 0 for a solid, 1 for
> a molecule
>
> SCF 7 0 100 0.1 1
>
> * kmax   [ delta_k  delta_e ] *** Upper limit of XANES
> calculation.
>
> * XANES 4.0
>
> * r_fms l_fms  *** Radius for Full Mult. Scatt. l_fms = 0
> for a solid, 1 for a molecule
>
> * FMS  16.77392  0
>
> * emin  emax   eimag   *** Energy grid over which to calculate DOS
> functions
>
> * LDOS  -30   20 0.1
>
> *** for EXAFS: RPATH 5.0 and uncomment the EXAFS card
>
> CRITERIA 0 0
>
> * POLARIZATION  0   0   0
>
> COREHOLE FSR
>
> RPATH 7.0
>
> LDOS -30 20 0.1
>
> EXAFS 20.0
>
>
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] customized dead-time correction in Larch

[Matt Newville]

Hi Esmael,

Without knowing the details of your dead-time correction, I would say
"maybe".  I think we could almost certainly add the code to do the
correction to the library.  How dead-time corrections get added to the GUI
might be a bit more work, but certainly possible.

Doing dead-time correction for a data file from an unknown
source/beamline/detector is sort of tricky.   There are many ways to
encode dead time (you might save ICR, OCR, LiveTime, DeadTime), and there
is no universal standard.  Some detection systems can have a two-stage
correction.  Even an easy-ish case might be:

 fluor_dtcorr = FeKa_MCA1*ICR1/OCR1 +  FeKa_MCA2*ICR2/OCR2 +  ... +
FeKa_MCA32*ICR32/OCR32

which is actually sort of painful to do programmatically.

This makes working with data needing dead-time correction challenging, as
some knowledge is needed about how to do that correction -- this makes
archiving data challenging too.  I would like to advocate for beamlines to
save a "dead-time correction factor" -- a simple multiplicative factor per
detector channel, or even better to save "dead-time correction total
fluorescence", especially for archiving data but even to make it useful in
analysis programs.

That is, I think it is ok for us to add some tools to help do dead-time
corrections but it would actually be better for everyone to have such
corrections done at or by the beamline.

That's probably not your actual question but may be slightly related. ;).
 I would say we could certainly try to add any functionality for doing
deadtime corrections.


On Fri, Apr 28, 2023 at 6:18 AM Esmael Balaghi <
esmael.bala...@fit.uni-freiburg.de> wrote:

> Dear Matt, Dear All,
>
> Is there a way to use our customized dead-time correction function in
> XAS viewer/Larch?
>
> Bests,
>
> Esmael
>
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] XAS Data pre-processing

[Matt Newville]

Hi Kumar,

These processing steps are separate because sometimes you might want to
alter the order. That said, here are my recommendations for normal
processing, with the strongest recommendations first:

I would not worry about choosing E0 or normalization until after merging.

If you need to align scans, do that before merging.  But see below on
"re-binning".

If you need to de-glitch multiple scans, first try to figure out why and
what energy values need to be de-glitched.  If these values are not
consistent across scans, it may indicate that your sample is causing the
glitches, which is not really consistent with "amorphous anatase".   If the
glitches are consistent and at nearly the same energies, you probably want
to de-glitch before merging.

Are you certain you need to re-bin the data?  If so, you should probably
consult with beamline scientists or people familiar with the data
collection on whether that should be done before energy alignment.  Some
data collection systems that generate data that needs rebinning probably
imply that you should *not re-align* at all, but trust the energy values.


On Sun, Apr 23, 2023 at 12:19 AM Kumar Jena 
wrote:

> Hi Ifeffit community,
> I am Kumar Jena, a PhD student at the University of Auckland. I have
> recently collected XAS data from amorphous anatase samples. I have read and
> seen many resources on performing data preprocessing, such as corrections,
> energy calibrations, etc. However, my question is, is there a specific
> order for doing so, or does it vary from data set to data sets?
>
> The order in which I have done it is as follows: (I have used Athena)
>
>- Import > Align data sets > Choose E0 and apply for all the scans >
>Merge them > Deglith the merged data > Rebin > Normalize
>
> Please advise if it's the right way to start.
>
> I appreciate your time and help.
>
> Kind regards,
> Kumar
>
> --
> [image: University of Auckland (UOA) - WEGO-ITN]
> *Kumar Debajyoti Jena*
> *M.Tech (IIT Kanpur)*
> *Ph.D. Student*
> Department of Chemical and Materials Engineering
> Faculty of Engineering
> The University of Auckland
> Mob: *(+64) 225155447*
> *THERE IS NO PLAN*ET *B*. Please think of the environment before you
> print this email.
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Issue with Larch interacting with other software

[Matt Newville]

Hi Luke,


On Thu, Apr 13, 2023 at 5:58 AM Luke Townsend 
wrote:

> Hi All,
>
> Apologies if this has been brought up previously but I wanted to see if
> anyone else has had some issues with other software installed on the
> computer interacting with Larch (particularly XAS Viewer) and resulting in
> Larch no longer functioning. A couple of colleagues/students have been
> running into this issue with the SEM software AZtec.
>
> The error code that has been reported is (I'm not sure how helpful this
> is):
>
> 'Entry Point Not Found - The procedure entry point H5Literate could not be
> located in the dynamic link library C:\Program Files\Oxford Instruments
> NanoAnalysis\AZtec\x64\HDF5_hl.dll.'
>
> If anyone has any suggestions for resolving this (without having to run
> two separate computers for each software which is our current work around)
> it'd be thoroughly appreciated.
>

Hmm, Sorry for the trouble. I don't know what would cause that.  It *should
be* that (by default) Larch installs its own Python interpreter and a full
stack of libraries and never looks or notices if there happens to be some
other Python environment installed.You *can* install it into an
existing Python environment -- that is allowed and not even really
discouraged, but it is sort of "advanced usage" in that it at least opens
up the possibility of conflicts.

That error message looks like Python is somehow seeing the HDF5 library
files from the Oxford AZtec installation.  I don't know why it would find
that.   I might suggest a few things in the "testing why this could be" and
a couple in the "workaround" category.

First, to track down why this happens, If you open a Python interpreter (or
even a "Larch CLI buffer", if that can run) you could try this:

 import h5py
 print(h5py.__version__)
 print(h5py.__file__)


For "workaround", first can you confirm what the Larch installation folder
is?  Like, did you install from the installer to
C:\Users\\AppData\xraylarch
or something similar?   Have you tried re-installing Larch?  I'm not
certain that will help

You might also check if there is some environmental variable that points or
that AZtec folder.  I think that H5PY does not use environmental variables,
so I'm not sure what to look for here.  But, you might just check what
"PATH" is, and maybe adjust that (maybe removing references to AZtec, at
least temporarily, or for a "launcher batch file" for Larch / XAS Viewer).

I hope that gives a few things to try that will help,

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Stand Alone Atoms

[Matt Newville]

Hi Yasin,


On Thu, Apr 13, 2023 at 7:20 AM Yasin Deep  wrote:

> Dear All,
>
> I want to calculate bond lengths of the SrFe2As2 parent compound for E//ab
> and E//c polarization with stand-alone atoms pack of the Demeter. How can I
> calculate bond lengths for these two different polarizations? There is a
> panel for polarization vector I guess that panel I should adjust. I should
> put (0,0,1) for E//c and E//ab (1,1,0) is this correct? What should I put
> let's say for 30 degrees of polarization? Thank you in advance,
>


The bond lengths won't depend on the polarization, of course, though the
interaction of that crystal with X-rays will.

Setting the polarization vector as with
  POLARIZATION 0 0 1

would put the polarization vector (not the electric field) along the `c`
axis, and
 POLARIZATION 1 1 0

will put it at 45 degrees (tau/8) between the `a` and `b` axes.

If I'm not mistaken, put it at 30 degrees (tau/12) from the "a" axis toward
the "c" axis you would say
  POLARIZATION 0.866  0.000 0.500

Hopefully, someone will correct me if that is not correct ;).



> Dr. Yasin HACISALIHOGLU
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Scattering paths in Artemis

[Matt Newville]

Hi Jyoti,

The scattering paths are held in the "feff.dat" files, and do not
necessarily need the feff.inp file that was used to generate them.  It is
fine to move those around, rename them, etc.   That just means that you are
then taking charge of managing and organizing them instead of letting
Artemis (or, say XAS Viewer) do that for you.

You can definitely use different scattering paths from multiple
calculations, including those done elsewhere.


On Thu, Apr 13, 2023 at 10:30 AM Jyoti Pandey 
wrote:

> Hello everyone,
>
> I have a question regarding the scattering paths.
> Can we manually feed the scattering paths in artemis or it will only read
> from the feff input file.
>
> Thank you.
>
>
>
> With Best Regards
>
> Dr. Jyoti Pandey, Ph.D.
> Postdoctoral Researcher
> Department of Physics
> Central Michigan University, MI, USA
> Mobile No. +1-9282650599
> .
>
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Exporting XANES data as a .csv file

[Matt Newville]

Hi Kumar,

Just to echo Carlo's suggestion, you can import the Athena project into XAS
Viewer and do the pre-edge peak fitting there.  Pre-edge peak fitting is
really significantly better in XAS Viewer than in Athena.   There are more
lineshapes available (including a non-pseudo Voigt) choices, and you can
place upper/lower bounds on each variable in the fit.   The Pre-Edge Peak
panel starts by wanting to define a "baseline" function describing the main
edge -- typically a line + a Lorentzian, and then you can add peaks from
there.

There is a video on using this at
https://www.youtube.com/watch?v=bd7PgaDpVc0


On Wed, Apr 12, 2023 at 10:53 PM Kumar Jena 
wrote:

> Dear, all,
> I am a new XAS user. I have done preprocessing of my data in Athena and
> have been trying to export the XANES data as a .csv file. I would like to
> fit the pre-peak region to pseudo-Voigt line shapes to extract approximate
> relative intensities of various transitions (A1, A2, A3, and B).  Attached
> is a screenshot from an article for your reference (
> https://doi.org/10.1021/jp981644k).
>
> Is it possible to do so in Athena?
>
> Any help would be appreciated.
> Kind regards,
> Kumar
>
> [image: image.png]
> --
> [image: University of Auckland (UOA) - WEGO-ITN]
> *Kumar Debajyoti Jena*
> *M.Tech (IIT Kanpur)*
> *Ph.D. Student*
> Department of Chemical and Materials Engineering
> Faculty of Engineering
> The University of Auckland
> Mob: *(+64) 225155447*
> *THERE IS NO PLAN*ET *B*. Please think of the environment before you
> print this email.
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@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] developer Zoom meeting

[Matt Newville]

Hi Folks,

As I mentioned a few weeks ago (
https://millenia.cars.aps.anl.gov/pipermail/ifeffit/2023-March/010594.html),
we are trying to start a monthly Zoom meeting to talk about the development
of Larch and related tools.

The first of these meetings will be this Friday, April 7 at 9 AM Chicago
(1400 UTC, I believe).  I'm reluctant to publish the Zoom link on this
forum, but if anyone is interested, send me a direct email.

I know this time is not convenient for many of you.  If you would like to
participate but cannot make this meeting, please let me know.  I think the
first order of business will be to work on a better day/time and
organization.

Thanks,

--Matt Newville 
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Fortran runtime error when running feff on Hydrotalcite cif

[Matt Newville]

Hi Siebe,

Sorry for the trouble.   I agree with Robert's suggestion to check whether
"Wat" might be causing the problem.

The CIF Browser and Feff runner in XAS Viewer does actually support
fractional occupancies, by randomly assigning atoms to match the partial
occupancy (but of course, not with great precision -- each X, Y, Z position
has exactly one actual atom of a determinant Z).  That allows a lot CIF
files to "just work" that would otherwise need manual intervention.  At the
moment (and possibly for the foreseeable future),  the CIF Browser does not
support editing the CIF directly, but does support editing the result
Feff.inp file, but one can export a CIF, edit that elsewhere, and then
import it.

What I see trying to run a calculation from that CIF file is that there are
many oxygen atoms that are too close together.  Like Robert suggested, I
suspected these come from the "Wat", but when I removed those and the H
atoms, the prolem still happened.  As Robert listed the atomic positions
for this structure, I think it might actually be the "C", "O2", as well as
the "Wat" with the low occupancy of "0.0833" that might be the problem.

If I remove CO groups and Waters, these to generate the attached CIF (I
changed the ID number) that seems to run, though I don't know if it is then
the structure you actually are trying to model ;).

--Matt


On Thu, Mar 30, 2023 at 6:51 AM van der Veer, Siebe 
wrote:

> Dear all,
>
> I'm trying to run feff on the Hydrotalcite cif file as can be found in the
> Larch Am Min CIF browser and I get the following error:
>
>
> *At line 125 of file ff2chi.f (unit = 1, file = 'list.dat')Fortran runtime
> error: Bad real number in item 2 of list input*
>
> I've been able to gather that this means there is some unreadable input in
> the file that is been used, but I don't know what file this is so I don't
> know what the actual bad input is and what has caused it.
>
> Any help is greatly appreciated!
>
> Kind regards,
>
>
> --
> *Siebe van der Veer* | *PhD student*
> Nanostructures of Functional Oxides | Zernike Institute for Advanced
> Materials
> University of Groningen | Nijenborgh 4, 9747 AG Groningen | The Netherlands
> Email: s.van.der.v...@rug.nl |
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411


Test1.cif
Description: Binary data
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Problem with cif file in larch

[Matt Newville]

Hi Eugenio,

Sorry for the trouble.  For sure, interpreting CIF files can be tricky!
But, I can read that CIF file with XAS Viewer, larch version 0.9.67.  It
doesn't fully read all the data about the publication, and it can generate
a plausible Feff.inp file.
Can you verify that you have a fairly recent version?

I see that there are Unicode characters in the file, but these seem to me
to be UTF-8 compatible.   If you are still seeing trouble, this might be
part of the problem.  You might have better luck if you remove these
(specifically the line with "_chemical_name_structure_type", which I think
you can just remove).   If that *does* help, can you also report what your
default Unicode encoding is: from either Python or the Larch buffer in XAS
Viewer, do

   import sys
   print(sys.getdefaultencoding())


Unfortunately, the current code is not super helpful in reporting why it
couldn't read the CIF file - this should be improved!



On Fri, Mar 24, 2023 at 2:20 AM Otal Eugenio 
wrote:

> Hi all,
> In November I was generating the feff-path in Larch using the .cif file I
> attached.
> Now I am generating additional paths from another absorbing atom and I am
> getting the error message "Error opening .cif file" using the same .cif
> file.
> Any ideas?
> Best regards.
>
>
>
> (^ㅇᆽㅇ^)(=˃ᆺ˂=)(= ༝ =)
>
> Eugenio H. OTAL
> Assistant Professor
> Dept. of Materials Chemistry
> Shinshu University
> 4-17-1 Wakasato, Nagano 380-8553, JAPAN
> eugenio_o...@shinshu-u.ac.jp
> https://sites.google.com/view/zettsu-laboratory/news-updates
>
> ___
> Ifeffit mailing list
> Ifeffit@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@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] monthly xraylarch developer zoom meeting

[Matt Newville]

Hi All,

A few of us would like to start having regular (or somewhat regular) Zoom
meetings to discuss planning and development goals for the xraylarch
project.  We would like to eventually settle on a stable-ish time for the
monthly meeting.  A doodle poll for the time of the initial meeting is at:

 https://doodle.com/meeting/participate/id/e99lKPze

I will send out an announcement by March 27th of when the first
meeting will be.

 There are many potential topics to discuss.  A  few that are on my mind as
topics for the next months/year might include:
   a) supporting (and perhaps working on design) of an XAS schema for
NeXuS/HDF5
   b) better support for using xraylarch from Jupyter, especially plotting
routines.
   c) creating inputs, launching, and reading of outputs for XANES
calculations with Feff and/or FDMNES.
   d) MCR-ALS or related additional linear algebra methods.
   e) improvement to XRF / XRF mapping schemas, formats, and analysis.

These discussions will sort of focus on what these codes and programs
should do, so anyone interested in working with Larch from Python or other
tools is definitely most welcome.  Having input from knowledgeable "power
users" or experts in the field would be great.

I think we don't want this to be a support forum, but if people would also
like to see "virtual office hours" (say, 1 hour per month for support
questions), please let me know.

Thanks,

--Matt Newville  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] XAS viewer unit detection during data reading

[Matt Newville]

Hi Edmund, Mauro,

I think that maybe relaxing the test to be "if it starts with the letter E
or e" and then also apply the current tests of the numerical data (sort of
like: are the numbers increasing? is the minimum value between about 100
and 150,000? is the average step size somewhere between 0.01 and 10?).

But also, if you or anyone else has a "typical beamline file" -- and
especially if there is a positive identifier for a beamline say the name of
the beamline in the first couple of lines of the file --  we can add that
to the files identified as XAFS data files.

OK, slight diversion:

I "almost agree" with Mauro's recommendation to distribute data in
HDF5/NeXus format instead of ASCII files. ;).

I am probably biased, but I think XDI (Ravel, et al J Synch Rad. 2012
https://doi.org/10.1107/S0909049512036886 and also Ravel and Newville, J.
Phys Conference, 2015 https://doi.org/10.1088/1742-6596/712/1/012148) would
be the preferred way to exchange XAFS data.   The 2012 paper actually
discusses HDF5 as well.

For HDF5/NeXus, I have a few slightly incompatible opinions that I think we
should resolve:
a) for many facilities, HDF5/NeXus is the preferred method for making
all data available especially to comply with F.A.I.R. guidelines (or
mandates).
b) I use HDF5 every day. It is the right tool for some jobs, but it has
some limitations.
c) The current NeXus definition for XAS data is actually not very good
and does not really comply with XDI or the discussion summarized in the J
Synch Rad paper.  I am not aware of anyone actually using this.  I am
willing to work on trying to get the NeXus XAS schema improved.
d)  We in the XAFS community should have a defined schema for NeXus
that better complies with the 2012 paper and XDI.

If anyone *is* collecting data into HDF5 or NeXus-like files, please send
examples -- we want to support them in Larch, but also we want to get to a
standard that is feasible.  If anyone is interested in participating in
discussions about "NeXus and/or HDF5 and/or similar for XAS",  please
contact me.

--Matt

On Wed, Mar 1, 2023 at 7:33 AM Edmund Welter  wrote:

> Dear Maurizio, Matt,
>
> I just checked why some older files from my beamline work correctly while
> the newer ones are not identified as xas data. After your explanation the
> reason is quite simple. In the old format the last line of the header was
>
> #enc_energy mono_energy mono_bragg Step_Pos mono_X1vert
>
> After rewriting major parts of the beamline software among other things
> the last line of the header changed to:
>
> # E_enc E_step Bragg_enc Bragg_step...
>
> Once I replace E_enc with something like energy_enc or enc_energy the data
> is correctly identified as xas data.
>
> So, the easiest solution for data taken at P65 is that I will change the
> header in the data file so that the first column has a name that contains
> "energy". I think i remember that Athena was looking for the first column
> were the value of every point n+1 is larger than the value of point n. it
> then usually correctly identified that column to be the energy axis.
> However, I think labeling the columns correctly, that means following
> common accepted conventions, is much easier than programming a bunch of
> complicated fail safe energy axis recognising procedures.
>
> Cheers,
>
> Edmund
>
>
>
> On 28.02.23 18:16, Matt Newville wrote:
>
> Hi Siebe,
>
> Just to agree with Edmund and Mauro:  selecting "energy" and changing data
> type from "raw" to "XAS" should help.  But, you would have to do this for
> every file, which is not ideal.
>
> The file reader is trying to guess whether data is in energy (and if so,
> what units are used) and whether it is really XAS data or some other kind
> of data. I suspect that it is defaulting to "raw" because the energy column
> is not labeled "energy", but "col1" -- it sort of looks like the reader is
> not doing a good job of guessing what the columns mean.
>
> Posting a file would help diagnose why it is guessing wrong.  The file
> reading does try to guess what beamline a data file came from, so if you
> send a file, maybe we can add enough hints for files from that beamline to
> work more reliably.
>
>
>
> On Tue, Feb 28, 2023 at 6:37 AM Welter, Edmund 
> wrote:
>
>> Dear Siebe,
>>
>> did you try to change the data type from "raw" to XAS. If you click on
>> the small arrow on the right you should have the choice between xas and
>> raw. On my computer that works and after that I can choose the unit for the
>> X-axis. For some reason "raw" seems to be the preset choice. Maybe Matt
>> could change that, I fell into this trap sever

Re: [Ifeffit] XAS viewer unit detection during data reading

[Matt Newville]

Hi Siebe,

Just to agree with Edmund and Mauro:  selecting "energy" and changing data
type from "raw" to "XAS" should help.  But, you would have to do this for
every file, which is not ideal.

The file reader is trying to guess whether data is in energy (and if so,
what units are used) and whether it is really XAS data or some other kind
of data. I suspect that it is defaulting to "raw" because the energy column
is not labeled "energy", but "col1" -- it sort of looks like the reader is
not doing a good job of guessing what the columns mean.

Posting a file would help diagnose why it is guessing wrong.  The file
reading does try to guess what beamline a data file came from, so if you
send a file, maybe we can add enough hints for files from that beamline to
work more reliably.



On Tue, Feb 28, 2023 at 6:37 AM Welter, Edmund 
wrote:

> Dear Siebe,
>
> did you try to change the data type from "raw" to XAS. If you click on the
> small arrow on the right you should have the choice between xas and raw. On
> my computer that works and after that I can choose the unit for the X-axis.
> For some reason "raw" seems to be the preset choice. Maybe Matt could
> change that, I fell into this trap several times.
>
> Cheers,
> Edmund
>
> --
> *From: *"van der Veer, Siebe" 
> *To: *"XAFS Analysis using Ifeffit" 
> *Sent: *Tuesday, 28 February, 2023 13:16:18
> *Subject: *[Ifeffit] XAS viewer unit detection during data reading
>
> Dear all,
> I am not sure if this mailing list is the correct medium for this
> question. Apologies, if not.
>
> I am looking to import files in XAS viewer, which worked fine in ATHENA,
> but in XAS viewer the correct units of the data are not detected and I
> cannot manually change them. I can get a plot of the data, but the data is
> not recognized by the software as XAS data, i.e. a lot of
> plotting/conversion options do not show.
>
> I hope the following screenshots provide sufficient information to
> illustrate my issue.
>
> Reading in a .dat file of fluorescence data. I can't change the units in
> the marked area.
>
> [image: image.png]
>
> The data can be read into the XAS viewer, but I don't have the regular
> plotting options in these dropdown menus.
>
> [image: image.png]
>
> Any advice would be much appreciated.
>
> Kind regards,
>
>
> --
> *Siebe van der Veer* | *PhD student*
> Nanostructures of Functional Oxides | Zernike Institute for Advanced
> Materials
> University of Groningen | Nijenborgh 4, 9747 AG Groningen | The Netherlands
> Email: s.van.der.v...@rug.nl |
>
> ___
> Ifeffit mailing list
> Ifeffit@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@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Error importing CIF files using Larch/ XAS Viewer

[Matt Newville]

Hi Jack,


On Wed, Feb 15, 2023 at 9:11 AM Jack Geary  wrote:

> Hello,
>
> I have encountered an issue recently where any CIF file I attempt to open
> in XAS Viewer for Feff calculations returns an error that the file cannot
> be imported. This occurs with any CIF I have tried (all downloaded from
> CCDC). Is there a workaround for this?
>
>
Sorry for the trouble. I know that many CIF files do work, but also that
CIF is not the most uniform of specs ;).

It's usually just a difference in some of the tags used, and so often not
too hard to fix the code to be able to read these, but I have also seen
some CIF files that are just not really describing a crystal structure.

Can you send a couple of examples of CIF files that don't work?  You can
send them to me by direct email if you like.

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Logical range for Amplitude Reduction Factor in EXAFS fitting results

[Matt Newville]

Hi Esmael,

Can you give specifics for what you see as "extremely large"?   In
principle, the amplitude reduction factor should be in the range of 0.7 to
1.0, but values a bit outside that range could certainly be believable.

In lots of EXAFS analyses S02 is used to compensate for several data
measurement and processing challenges, including the energy resolution of
the measurement and normalization by the edge step in addition to the
intended purpose of accounting for the not-quite-perfect estimate of the
S02 factor in the EXAFS calculations.

There is also the sort of inherent room for confusion about where the
coordination number is folded into the overall amplitude -- sometimes one
wants to fix the coordination number and sometimes one wants to vary it,
and what gets reported as "amplitude" can vary quite a bit.

--Matt

On Tue, Jan 24, 2023 at 8:41 AM Esmael Balaghi <
esmael.bala...@fit.uni-freiburg.de> wrote:

> Dear All,
> I noticed that some published works have reported extremely large values
> for the amplitude reduction factor. This seems a bit unusual, as the
> amplitude reduction factor is typically expected to be in the range of 0 to
> 1. I am curious to know what could be the reasons behind it to get such
> large values for the amplitude reduction factor during EXAFS fitting.
>
> Thank you in advance for your insights.
>
> Esmael
> ___
> Ifeffit mailing list
> Ifeffit@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@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Using 3 or more CIF file for fitting in Artemis

[Matt Newville]

Hi Esmael,

On Fri, Dec 16, 2022 at 3:36 AM Esmael Balaghi <
esmael.bala...@fit.uni-freiburg.de> wrote:

> Dear all,
>
> Following the previous discussion (
> https://www.mail-archive.com/ifeffit@millenia.cars.aps.anl.gov/msg07118.html
> ) on using more than one CIF file for fitting, as Scott Calvin and Matthew
> Marcus suggested, we can fold the molar ratio into the amp parameter for
> each CIF. Does it mean that the overall S02 for all phases (all used CIF
> files in the fitting) is "set" to 1?
>

I would recommend thinking of S02 as a value that belongs to all paths of a
data set, and is part of - but not the whole of - the amplitude for any
path.

Typically, for the regular fitting with one model (cif file or any
> simulated feff file), we take the S02 value from the known metal foil that
> has been measured simultaneously with the unknown sample.
>
> So if we used the mentioned method and folded the molar ratio into the
> amp, does it mean in Artemis we use the following terms?
>
> "in Artemis: S02= abs(amp) for one phase and for another one: S02=
> abs(1-abs(amp)" and leave “amp” parameter to “guess”
>

When mixing structures from different CIF files there can be a slightly
tricky issue that each path file has a coordination number built in, and
this might be different for different structures. Like, for a perfect
octahedron, this "degen" would be 6, but if another structure with the same
neighboring atom has a distorted octahedron, some paths might have a degen
of "1" or "4" or something else.

If that is the case, I would suggest forcing all the "degen" values to 1,
and then using "S02 * N1"  for the amplitude term of path 1 and "S02 * N2"
for the amplitude term of path 2, etc, and then define/constrain N2 to be
"6- N1" (or whatever you think is appropriate total coordination is).

On the other hand, if you are mixing different phases, and you expect (for
example) there is some Pt metal that is well-defined by a single structure
("CIF") and also some Pt oxide (also with a well-defined structure), and
the question is "how much oxide is there", then you might leave the path
degeneracies as calculated from the structures and use

"S02 * Fraction_Ptmetal" for the Pt-Pt Path from the Pt structure, and "S02
* Fraction_PtOxide" for the Pt-O Path from that structure, and then
define/constrain "Fraction_PtOxide = 1 - Fraction_Ptmetal".

Either way, you can set "S02" as appropriate (say, found using a spectrum
of a standard with well-known coordination", and you have easy access to
trying different combinations of coordination numbers or compositional
fractions.


Also if we are using X, Y, Z, CIF files, does it mean the summation of
> all S02 for all X,Y,Z,... cif models would be equal to 1? Im not sure, but
> I guess in this work (
> https://www.sciencedirect.com/science/article/pii/S001670370200 ),
> the authors used this way and fixed the overall S02 for all phases to 1.
>
I would appreciate having your comment on this method or if you have any
> suggestion on how to deal with the S02 value in Artemis when we are using
> more than 2 or 3 phases (cif files) for the fitting process.
>

If the idea is that you have a mixture of Pt metal, PtO, and PtCl, you
could use path amplitudes of
"S02 * Fraction_Ptmetal"
"S02 * Fraction_Ptchloride"
"S02 * Fraction_Ptoxide"

let the first two fractions vary and define/constrain "Fraction_PtOxide = 1
- (Fraction_Ptmetal + Fraction_Ptchloride)".

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Plotting chi(R) from FEFF in XAS Viewer (Larch) with phase correction

[Matt Newville]

Hi Liam,

Yes,  this is not currently available.  It would not be hard to enable, but
I am not sure it is a great thing to do. I admit that I sort of find that
phase-correction plots need a lot of explanation, and so are prone to
causing confusion.  They might be useful for Pt metal, but they cannot
really be correct for multi-atomic systems.  Well, I guess "correct" is not
the only consideration ;).

I guess I would ask if there are suggestions and input from people teaching
XAFS on whether phase corrections (and probably a handful of other "tricks"
or analysis variations) are actually useful or just confusing.




On Tue, Dec 13, 2022 at 7:58 AM Liam Nagle-Cocco  wrote:

> Dear all,
>
> In Artemis it is possible to plot chi(R) for FEFF-fit, with the phase
> corrected - i.e. bond length corrected for deltaR. This is shown in this
> screenshot below ("Use this path for phase corrected plotting"). Is this
> possible in XAS Viewer?
>
>
> Liam Nagle-Cocco *(he/his)*
>
> PhD Student in Condensed Matter Physics | Cavendish Laboratory
>
> Welfare Officer 2022-2023 | Jesus College MCR
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Installing Larch without installing Anaconda

[Matt Newville]

Hi Laurent,

Hopefully, you saw the earlier replies - if not, see the archived messages
at
https://millenia.cars.aps.anl.gov/pipermail/ifeffit/2022-November/thread.html

The basic answer is that you do not need to use Anaconda to run Larch on
macOS.   There is a MacPorts port available, for example.  In fact, Larch
is distributed with PyPI so you should (or at least "may") be able to
install it in any Python environment, provided the dependencies are also
available.

I also agree with Dr. Kumar's response that installing into a
system-provided Python may not be the best idea (on any system, but
especially macOS).   Python does support virtual environments pretty well,
which I would highly recommend to anyone wanting to install using a
system-provided Python.

If you have tried installing Larch and run into trouble, let us know what
you tried and what did not work.


On Mon, Dec 12, 2022 at 10:14 AM TRANCHANT Laurent <
laurent.tranch...@synchrotron-soleil.fr> wrote:

> Dear Mr or Mrs,
>
> I sent you this message about ten days ago but on my side I did not
> receive any answer.
> I would like to avoid installing Anaconda during the installation of Larch
> on my MacOS computer. I would like to know if it is possible or not.
>
> I thank you in advance for your help.
>
> Best regards,
>
> Laurent Tranchant
>
> --
> *De: *"TRANCHANT Laurent" 
> *À: *"ifeffit" 
> *Envoyé: *Mercredi 30 Novembre 2022 13:49:11
> *Objet: *Installing Larch without installing Anaconda
>
> Dear Mr or Mrs,
>
> I am Laurent Tranchant, post-doctoral researcher working at the IPANEMA
> laboratory at the SOLEIL synchrotron in France.
> I would like to install Larch (especially to use XAS Viewer to treat my
> XAS data) without installing Anaconda on MacOS. Do you know if it is
> possible or not ? For example by using MacPorts instead of Anaconda...
> It seems that all the solutions proposed online to install Larch on MacOS
> require the installation of Anaconda Python environment.
>
> I thank you in advance for your help.
>
> Best regards,
>
> Laurent Tranchant
>
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Installing Demeter on macOS Ventura

[Matt Newville]

Hi Yasin,


On Sun, Dec 4, 2022 at 11:46 AM Yasin Deep  wrote:

> Hi Dear All,
>
> I'm very new on MacOs and I'm trying to install demeter on MacOs Ventura.
>
>
>1. I have Installed Xcode from MacOS App Store and,
>2. Agreed Xcode license in Terminal: sudo xcodebuild -license
>3. I have Installed MacPorts for my Mac operating system:
>   - macOS Ventura v1
>   
> 
>   3
>
> Later while I applied sudo port install xorg-server demeter I get
> attached error message. What should I do from now on Could you please help?
>
> Best Regards,
>
> Dr. Yasin HACISALIHOGLU
>
>

I think that you probably need to do both

xcodebuild -license
xcode-select --install

and it would probably help to install XQuartz (link on the MacPorts page).

But, I just tried this too, on macOS 13.0 (Ventura).  It looks like
MacPorts does not yet have binaries for Ventura, and so will build
everything (including compilers and system-level libraries) from source
kits.  That could easily take 6 hours and might be much more.  I've had
poor luck with MacPorts especially with trying to get GUI apps to run, but
I'll see how it goes (currently compiling libgcc12!).  If you have the
patience to try this too, please let us know how it goes!

If you are interested, Larch and its XAS Viewer GUI App have many of the
features of Athena and Artemis and do install and run on macOS.
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Installing Larch without installing Anaconda

[Matt Newville]

Hi Laurent,

On Wed, Nov 30, 2022 at 9:05 AM TRANCHANT Laurent <
laurent.tranch...@synchrotron-soleil.fr> wrote:

> Dear Mr or Mrs,
>
> I am Laurent Tranchant, post-doctoral researcher working at the IPANEMA
> laboratory at the SOLEIL synchrotron in France.
> I would like to install Larch (especially to use XAS Viewer to treat my
> XAS data) without installing Anaconda on MacOS. Do you know if it is
> possible or not ? For example by using MacPorts instead of Anaconda...
> It seems that all the solutions proposed online to install Larch on MacOS
> require the installation of Anaconda Python environment.
>

Yes, as Carlo says, I think it should be possible to install Larch on MacOS
with Python from Python.org and probably from MacPorts too.

The main requirements are "the normal scientific python stack" which should
be available with essentially every distribution.   To get the GUIs,
wxPython is required.  PyPI has this for MacOS (and Windows), so that it
should work.

I think I have not tried Larch with MacPorts or "Python.org Python" on
MacOS for a few years.  But if you are interested, I would say to go ahead
and try, maybe even start by trying `pip install xraylarch`.  If you're
interested in using the GUIs, do `pip install wxmplot` (to be clear,
wxPython is not a requirement for using Larch as a library, but is needed
for the GUIs).  Let me know how it goes or if you run into any problems or
have any questions.



--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] XANES temperature estimation (Robert Gordon)

[Matt Newville]

Hi Gabriele,


On Mon, Nov 21, 2022 at 12:59 PM Gabriele Garofalo <
gabriele.garof...@esrf.fr> wrote:

> Hi Gordon,
>
> I have just one spectrum per sample, all taken at different T (unknown,
> due to technical problems) and P (known). I'd like to find T and using
> an EoS is not a viable option.
> I was thinking that maybe, assuming that the Debye-Waller term is
> explained only by thermal disorder, the Debye temperature is P
> independent, and there are no structural or electronic transformations,
> I could retrieve T by fitting the Debye-Waller term and using the
> reference spectra. Is this possible?
>


It seems unlikely to me.  XANES is typically described as probing the
electronic states of a sample.  There is, of course, a strong connection
between atomic/nuclear structure and electronic structure, but the changes
in thermal structural disorder with temperature are actually pretty small.
Interference-sensitive measurements (EXAFS, XRD) will be sensitive to such
changes, but XANES is much less so.  When describing an EXAFS
Deybe-Waller model, the amplitude decays as exp(-2k^2*sigma^2).  When k is
very small (ie, XANES), you need to have sigma be very large for that to
make much of an impact in the XANES region.

Some XANES features (such as pre-edge peak intensities) can have some
temperature dependence - these are sensitive to small changes in the
overlap of specific electronic levels.  But, in general, the XANES features
don't have a strong temperature dependence.

But, I guess we should ask: do you see a significant variation in your
XANES spectra with temperature?

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] How to normalize tens of thousands of XAS data?

[Matt Newville]

You might find larch and Python useful here.   Of course, you would have to
code in some particulars about where and in what format your data is
stored, but the XAFS pre-edge subtraction and normalization step is a
single Python function with larch, maybe omething like this:

``` Python script
#!/usr/bin/env python
from glob import glob
from larch.io import read_ascii
from larch.xafs import pre_edge

filelist = glob.glob('MnXAFS*')

groups = {}
for fname in filelist:
thisgroup = read_ascii(fname, labels='energy ctime i0 i1 i2 mnka')
thisgroup.mu = thisgroup.mnka / thisgroup.i0

pre_edge(thisgroup, pre1=-200.00, pre2=-35.00, norm1=150.00,
norm2=350.0)
group[fname] = thisgroup

# now you have several normalized XAFS spectra... and now what?

```

That makes a fair number of assumptions about how data is configured (plain
text files, with columns as labeled) and how it should be processed, but it
might give you an idea of how to start.


On Tue, Nov 15, 2022 at 1:38 AM 张驰  wrote:

> How to normalize tens of thousands of XAS data?
>
> I measured a series of the spectra of sample over time by in situ XAS, the
> results contained tens of thousands of sets of XAS data, and it was
> impossible to normalize each set of data individually.I would like to ask
> where to find the normalized source code of Athena, I can modify the code
> so I can use my computer to achieve a large number of processing.Thanks!
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] found some issues found in larch (read-in issues)

[Matt Newville]

Hi Stefan,

Thanks, that's all very helpful. As Mauro says, some of these might be
known already, but I'm not 100% certain of that.

On Wed, Oct 26, 2022 at 4:47 AM Mangold, Stefan (IPS) <
stefan.mang...@kit.edu> wrote:

> Dear All, dear Matt,
>
> all tests were done on Macs (one M1 & one Intel) with the latest version
> your software & latest OS.
>
> 1. Read-In of spec files works, but only one file at once. Even if
> multiple files are selected
>

Yes, "read in many" is limited to plain text column files that are expected
to hold 1 spectrum and have a uniform layout.  Reading in spectra from Spec
files, Athena Project files, and other "multi-spectrum files" would
potentially be a bit more complicated -- which spectra from which file
would you need?   I guess we could assume "every spectrum", but with a Spec
file, you still need to select columns.Maybe you have more uniform Spec
files than the ones I normally see, but I'm not sure I know that "read
every scan from multiple spec files" would be reliable.


To be clear, I'm completely fine with *trying* to read in as many types of
"data directly from beamlines" as possible, while also recognizing that
this is a bit of a moving target and admitting that some data formats might
have higher priorities than others.   For sure, trying to better support
HDF5 and NeXuS is a priority.



> 2. If one tries to load text-files it is possible to load data form
> multiple files as long as you don’t try to load also the reference spectra.
> If you load the reference  also the read-in stopps at the
> transmission/fluorescence spectrum of the second file selected.\


Do you get any messages when this happens?   I'll investigate.   As Mauro
says, it might be related to another "known problem", but that doesn't mean
it is completely solved ;)
.

>
>
> 3. Trouble, that I sometimes can’t unmount network volumes after reading
> from them, larch saved on local discs. MacOS claims that python has files
> open; no other python program running


I have not seen this but I'll see if I can reproduce that.   Files are
generally closed after reading or at least meant to be. ;).


>
> 4. unable to save the data of one XAS-viewer while having two xas-viewer
> open.


As Mauro says, I think we may have seen and solved this one.  But, if you
have error messages or further information on what you see when this
happens, that might be helpful.

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Help for EXAFS fitting

[Matt Newville]

Hi Dien,

When I look at your project, I find that I have to add Parameters to the
GDS page for the "P1.1" path.  When I include that in the fit, the
coordination number for that Path goes to 0 (0.07 +/- 0.3) and that
"ss_P11" is -0.03 +/- 0.04.  Both "P1.1" and "P1.4" show values for "delr"
that are above 0.8 Ang, pushing them both to be at R ~ 4.0 Ang.

My guess would be that those might not be the best paths to use here.  It
does look like there is something with R ~ 3.8 Ang, but I might I
am not sure I can guess what that is...


On Fri, Sep 9, 2022 at 11:32 AM dien...@srnl.doe.gov 
wrote:

> Hi, Matt and Carlo and other EXAFS experts
>
>
>
> Attached please find a fpj data file. The basic system is silica + PO4
> ligand on surfaces, which was used for adsorption of La. We collected La
> L3-edge EAXFS data and did this fitting. I used two models of La binding as
> monodentate and bidentate. I saw the negative ss parameter. I saw this in
> some of my other EXAFS data fitting samples as well. I have two questions
> for help:
>
>1. What might cause the negative ss parameters and how I may improve
>this, is this caused by incorrect structure models
>2. If we can do some “stress” test to make sure the fitting is valid
>and meaningful.
>
>
>
> Please you can help look at and play this data set and direct me on how to
> do this correctly, thank you so much.
>
>
>
> Dien Li
>
> Savannah River National Laboratory
>
>
> ___
> Ifeffit mailing list
> Ifeffit@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
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Larch: Fitting error of the objective/model function

[Matt Newville]

Hi Fan,

Sorry for the trouble.  That seems like a strange error to me - I don't see
why changing those expressions for E0s (even if they are  "slightly
complicated"!) should generate NaNs or Infinities.  I don't think I've seen
that happen with "feffit" fittings.   Can you send me a Larch Session File
with this fit in it?

 One suggestion is to place bounds (say +/- 20 eV) on those Parameters, say
   pars.del_e0_11=param(expr='0.5*del_e0_O+0.5*del_e0_Sr', min=-20, max=20)

But I'm not certain whether that would solve this problem.


On Wed, Sep 14, 2022 at 7:53 AM  wrote:

> Dear All
>
>
>
> I am doing Temperature-dependent EXAFS experiment with a lot of data.
>
>
>
> Usually, we do these kinds of data fitting by several steps, like below:
>
> First, put every parameter free, and obtain the averaged value of amp.
>
> Second, set the amp to the averaged value, put other parameters free, and
> then obtain the averaged value of del_e0.
>
> Third, set the amp and del_e0 to the averaged value, and fit again.
>
>
>
> In my case, my sample is perovskite structure (Ti K-edge of SrTiO3).
>
> To increase the fitting accuracy, I use three del_e0 for O, Ti, Sr as
> suggested in paper: Haskel, D., et al. Physica B: Condensed Matter 208
> (1995): 151-153.
>
> The fitting parameters of Cubic model is this:
>
> setattr(pars, f'alpha', param(0, vary=True))
>
> setattr(pars, f'amp',  param(0, vary=True))
>
> setattr(pars, f'del_e0_O',   param(0, vary=True))
>
> setattr(pars, f'del_e0_Sr',   param(0, vary=True))
>
> setattr(pars, f'del_e0_Ti',   param(0, vary=True))
>
> setattr(pars, f'sig2_O',  param(.002, vary=True))
>
> setattr(pars, f'sig2_Sr',  param(.002, vary=True))
>
> setattr(pars, f'sig2_Ti',  param(.002, vary=True))
>
> setattr(pars, f'sig2_Tr1', param(.002, vary=True))
>
> setattr(pars, f'sig2_p',   param(.002, vary=True))
>
> setattr(pars, f'sig2_Tr2', param(.002, vary=True))
>
>
>
> #del_e0 for each path
>
> pars.del_e0_1=param(expr='del_e0_O')
>
> pars.del_e0_2=param(expr='del_e0_O')
>
> pars.del_e0_3=param(expr='del_e0_Sr')
>
> pars.del_e0_4=param(expr='del_e0_Ti')
>
> pars.del_e0_5=param(expr='del_e0_O')
>
> pars.del_e0_6=param(expr='0.5*del_e0_O+0.5*del_e0_Ti')
>
> pars.del_e0_7=param(expr='(2*del_e0_O+del_e0_Ti)/3')
>
> pars.del_e0_8=param(expr='(2*del_e0_O+del_e0_Ti)/3')
>
> pars.del_e0_9=param(expr='(2*del_e0_O+del_e0_Ti)/3')
>
> pars.del_e0_10=param(expr='(2*del_e0_O+del_e0_Ti)/3')
>
> pars.del_e0_11=param(expr='0.5*del_e0_O+0.5*del_e0_Sr')
>
>
>
> In the first step, the fitting is fine, I obtained the averaged amp.
>
> However, in the second step, when I set amp to the averaged value, Error
> happens for “some” of the data.
>
> When I use different averaged amp value, the data that happens error is
> different.
>
> The error is:
>
> Traceback (most recent call last):
>
>   File "STO16_C_2.py", line 250, in 
>
> out = feffit(pars, dset)
>
>   File
> "D:\anaconda3\envs\xraylarch\lib\site-packages\larch\xafs\feffit.py", line
> 557, in feffit
>
> result = fit.leastsq()
>
>   File "D:\anaconda3\envs\xraylarch\lib\site-packages\lmfit\minimizer.py",
> line 1689, in leastsq
>
> lsout = scipy_leastsq(self.__residual, variables, **lskws)
>
>   File
> "D:\anaconda3\envs\xraylarch\lib\site-packages\scipy\optimize\minpack.py",
> line 423, in leastsq
>
> retval = _minpack._lmdif(func, x0, args, full_output, ftol, xtol,
>
>   File "D:\anaconda3\envs\xraylarch\lib\site-packages\lmfit\minimizer.py",
> line 601, in __residual
>
> return _nan_policy(np.asarray(out).ravel(),
>
>   File "D:\anaconda3\envs\xraylarch\lib\site-packages\lmfit\minimizer.py",
> line 2436, in _nan_policy
>
> raise ValueError(msg)
>
> ValueError: NaN values detected in your input data or the output of your
> objective/model function - fitting algorithms cannot handle this! Please
> read
> https://lmfit.github.io/lmfit-py/faq.html#i-get-errors-from-nan-in-my-fit-what-can-i-do
> for more information.
>
>
>
> I don’t know what happened, can somebody help me figure this out?
>
>
>
> PS: when I use only one del_e0 for every path, no such error happens.
>
>
>
> Best regards
>
> Fan
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Fitting multiple spectra simultaneously with Larch

[Matt Newville]

Hi Casey,


Sorry for the late reply - I see that you asked this question 2 weeks ago
- I think I got the same question from someone else by private email the
same day  I have had this question several times this summer.  Anyway,
sorry for missing this.

Larch can definitely fit multiple spectra at one time, co-refining
parameters.   An example of fitting 3 datasets (Cu K edge at 3
temperatures) is at

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

That is, you create several "Feffit datasets".  Each of these has a group
for the chi(k) data, a "transform" that gives the Fourier (or Wavelet)
Transform configuration and the fitting ranges, and a list of Feff Paths.

Different data sets can use the same transform and reuse Feff Paths. You
will also have a Parameter Group with all the variables and other
Parameters used to calculate the Path Parameters for each Feff Path.
Anyway, yes, Larch can definitely fit multiple datasets.

But: The XAS Viewer GUI does not currently (yet?) support this -- it helps
build a model, do the fit, and inspect the results for one dataset.  It
also helps write out the larch script to do the fit.  One approach could be
to use that:  use the GUI for "simple stuff" and interactive data
exploration, but use a script for more complicated and involved analyses.

I'm not opposed to adding fitting of multiple data sets in the XAS Viewer
GUI, but implementing it in the current GUI framework seems challenging (it
was definitely challenging for Artemis too).   I've heard some good
suggestions, but I'd be curious to hear (either here or via private email)
what others would like to see or suggest.

I guess that question really extends to other aspects of Larch and XAS
Viewer: if there are features, analysis approaches, or GUI tools that you
think could be better, let me know.

On Mon, Sep 12, 2022 at 11:30 AM Van Stappen, Casey M <
casey.vanstap...@austin.utexas.edu> wrote:

> Dear Ifeffit team,
>
>
>
> I’d like to fit multiple EXAFS spectra simultaneously in Larch using
> several common parameters/relative restraints, but have not found a way to
> do so (yet). I’ve gone through Dr. Matt Newville’s youtube tutorials
> (generally very helpful), but this topic doesn’t seem to have been covered.
> Any suggestions? Thanks!
>
>
>
> Best,
>
>
>
> Casey Van Stappen
>
>
>
> 
>
> Dr. Casey Van Stappen
>
> University of Texas at Austin
>
> Robert A. Welch Hall, 4.318
>
> 2350 Speedway
>
> Austin, TX 78705
>
> USA
>
>
>
> Phone: +1 (512) 775-2658
>
> E-mail: casey.vanstap...@austin.utexas.edu
>
>
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Icon Resolution issue in 14 inch

[Matt Newville]

Hi Mohamad,

On Sun, Sep 11, 2022 at 8:17 AM Mohamad Numan 
wrote:

> Dear Developers,
>
> I am using the Demeter package on my windows 11 laptop. I am facing some
> resolution issues in the icons of Athena and Artemis. The icons look pretty
> dull and very distressing to the eyes. Attaching a screenshot for
> your reference.
>
> I will be happy to hear an update from you.
>

The screenshot looks sort of normal to me.  I'm not sure I follow what
looks "pretty dull" to you... do you mean the icons in the system tray or
the graphical elements on the main window, or something else?

If you have specific expertise in graphical or user interface design, I'm
sure we would all be eager to have help with that.
--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Question related to an example of EXAFS fitting using Larch

[Matt Newville]

Hi Harry,

On Mon, Aug 29, 2022 at 2:43 PM Andy Zhang  wrote:

> Dear all,
>
> I am learning Larch and read the manual of Larch online. In the "13.8.10.
> Example 3: Fit 3 datasets with 1 Path" of the webpage
> https://xraypy.github.io/xraylarch/xafs_feffit.html#example-3-fit-3-datasets-with-1-path-each,
> it shows an example that fitting Cu at different temperatures.
> Einstein model was used to simulate the sigma2, as shown in the figure
> below.
>
> [image: image.png]
>
> However, in some papers (eg. Radiation Physicsand Chemistry137 (2017)
> 93–98) that model EXAFS at elevated temperatures, they separates the total
> sigma2 to static and thermo components (Sigma^2 = Sigma_static^2 +
> Sigma_thermo^2), which is different from the above Larch example.
>
> I am a little confused about the utilization of Einstein model. I wonder
> if the Sigma2 obtained by Einstein model can reflect the total sigma2 or
> can only reflect the thermo part.
>
>
The Einstein model is one way to map the effect of sample temperature and a
single parameter (Theta, the Einstein temperature, which can be related to
bulk thermodynamic properties) to sigma^2 and be applicable to several
different XAFS paths that involve the same set of atom types.  It won't
account for static disorder very well.

It is very common to break sigma^2 (which is the mean-square variation in
bond lengths) into "static" and "thermal" components.  This is convenient
but a little bit artificial (or, maybe "a model we often use").  The
"static" component will typically reflect the distribution of distances due
to differences in crystal structure:  say you have a crystal structure with
distorted octahadra  - the variations in the resulting bond lengths won't
be so big that you need to treat them as different scattering paths, but
needs to be taken into account, and can be mapped to calling that "static
disorder".   The "thermal" component would be solely from thermal
vibrations and might be modeled with an Einstein model or other models.

In the ~femtosecond lifetime of each photo-electron, the neighboring atoms
do not move, and the measurement is sampling billions of snapshots of the
atomic distances - it is not actually seeing the motion of the atoms.   A
thermal component to sigma2 can be determined only by measuring at
different temperatures.  Also: that "static disorder" might change with
temperature too, say at a phase transition.

With the pedantic lecture sorry!) aside,  the static/thermal distinction is
definitely useful, and for many materials is a completely valid way to
think about sigma2. To add a static disorder term to the thermal component
from `sigma2_eins()`, you could add a `sigma2_static` parameter with
something like

 pars = group(amp= param(1, vary=True),
 del_e0 = guess(2.0),
 theta  = param(250, min=10, vary=True),
 sigma2_static = guess(0),
 dr_off = guess(0),
alpha  = guess(0) )

  path1_10 = feffpath('feff0001.dat',  s02 = 'amp', e0 = 'del_e0',
deltar = 'dr_off + 10*alpha*reff',
sigma2 = 'sigma2_static +
sigma2_eins(10, theta)')

  path1_50 = feffpath('feff0001.dat',  s02 = 'amp', e0 = 'del_e0',
deltar = 'dr_off + 50*alpha*reff',
sigma2 = 'sigma2_static +
sigma2_eins(50, theta)')
  path1_150 = feffpath('feff0001.dat',  s02 = 'amp', e0 = 'del_e0',
deltar = 'dr_off + 150*alpha*reff',
sigma2 = 'sigma2_static +
sigma2_eins(150, theta)')

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] third cumulant in Larch

[Matt Newville]

Hi Harry,




On Fri, Aug 19, 2022 at 9:10 AM Andy Zhang  wrote:

> Dear all,
>
> I have a quick question related to EXAFS fitting using Larch. I wonder how
> to include the third cumulant in the fitting. I tried to add "third" in the
> "pars" section, but it seems it did not work.
>
> [image: image.png]
>
> Thanks a lot for your help!
>
>
By itself, that just sets up the parameters to be varied during the fit.
It does not specify how those will be used.

So: did you use the parameter named "third" in any of the Path Parameter
definitions?  Something like this

 path1 = feffpath('feff0001.dat',   s02 = 'amp', e0 = 'del_e0',
 sigma2='sigma2_eins(300, theta)',
   deltar='alpha*reff',
   third='third')

should work.

If not, please post a complete, minimal example showing what you are doing.

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Standardized Spectra

[Matt Newville]

Hi Kyle,

On Sun, Aug 7, 2022 at 8:15 PM Kyle Draim  wrote:

> Hello!
>
> I don't have any X-Ray data to analyze in your app, I'm just seeking a
> visual display of each element's standardized/accepted X-Ray spectra
> (instead of a table of numbers). So far, I've downloaded the application,
> but I'm stuck on how to find this information.
>

"X-ray data" and "X-ray spectra" are somewhat ambiguous.   In my
experience, the generic "X-ray data" often implies X-ray fluorescence
spectra, X-ray powder diffraction data, or an X-ray astronomy instrument
(say, Chandra).

We're mainly dealing with X-ray absorption spectroscopy (XAS) data here.
But if you want "X-ray spectra" for each element, that may not really mean
XAS, which will depend not only on the element but also on its atomic
environment.

Anyway, for XAS data, there are some example data included with the
software we use, see

https://github.com/xraypy/xraylarch/tree/master/examples/xafsdata, and
https://github.com/bruceravel/demeter/tree/master/examples/data

There are also online databases of experimental spectra at

https://xaslib.xrayabsorption.org/, and
https://mdr.nims.go.jp/

(FWIW, I would not recommend the data at the Lytle database - these data
files are hard to turn into usable spectra, and the quality is spotty.)

There are also calculations of predicted XAS spectra for some materials at
https://next-gen.materialsproject.org/xas.

To be clear, all of these spectra are represented by tables of numbers...
which kind of leads me back to thinking you might not be asking about XAS
data.

Anyway, I hope that helps,

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] xraylarch

[Matt Newville]

Hi Paul,

On Fri, Aug 5, 2022 at 8:41 AM Paul Fons  wrote:

> Hi.
>   Due to the difficulties of getting demeter to work on the Apple M1
> machines, I have started to use xraylarch and so far I like the interface
> as well as the possibility of scripting later on. I had a couple of
> observations and a question regarding xraylarch usage that I hope could be
> addressed here.
>
>
Thanks -- I gave some short answers to this at Github, but I thought I
would respond here too, as there might be people with thoughts on this
stuff here.

First, one can load multiple spectra into the (feff) fitting window. It
> seems, however, that which paths are selected are universal (the selected
> paths are used for all exafs spectra). Does this mean that multiple edge
> fitting is not possible. If multiple edge fitting is possible, how is it
> done?
> In the fitting window, one can have several spectra loaded and one can
> select all or some of the spectra to be fit. The interface seems like it
> was designed for multiple edge fitting, but is it?
>

Right now - and maybe for a while - the XAS Viewer GUI only supports
fitting 1 data set at a time. My view is kind of that "a GUI for simple
stuff, and scripts for complex stuff" is a reasonable starting point. But
also, fitting 1 data set at a time is just more complicated and harder to
expose as a GUI. Suggestions welcome!


> Second, it is strange that whenever a parameter is changed that the
> fitting variable settings (fixed, vary, constrain) are reset. For complex
> fits, this generates a lot of unnecessary clicking (and the corresponding
> mistake possibilities)
>

Yes, I agree.  I think this can be better (and a few things in this area have
been updated in the devel version). Having others using this in recent
short courses also showed similar problems, including when using >8 paths
and using many variables.  It's still kind of a work in progress and this
kind of feedback is really helpful.



> Third, when one reads in several different feff calculations, one would,
> in principle, like to have a different value of e0 (the origin of energy
> offset) for each feff calculation. By default when a feff calculation is
> read in the variable e0 is defined. When one defines alternative energy
> offset variables for the different feff calculations and deletes the
> original e0 value, something strange happens. Accessing the “Edit
> Parameters” window results in e0 reappearing (even though it has been
> manually deleted previously). Is this a feature? The same thing may happen
> for other “automatic” variables as well.
>
>

First, yes it does look like a bug that XAS Viewer insists on having
Parameters named "e0" and "s02". Will investigate, hopefully pushing a fix
in a month or so...

Second, I think that creating a different "e0" for each Feff run is a good
idea.

In fact, it would probably be reasonable to read the "Vint" value from the
feff.dat file and use "E0 Path Parameter = vint + e0_feff_run". vint
could even be (like Reff) a per-path variable, and the variable for E0
could be (by default) the same for all paths from a single Feff run, but
different for different Feff runs.

I think there are no clear results on whether using the value of
per-feff-run vint was good enough to make a single e0 variable really
independent of the Feff run.  I do believe that the values for vint are
pretty good with Feff8, but It would be interesting to try to figure out
how to test this well.   If you or anyone else has an opinion or thoughts on
any of this, that would be valuable.


Four. This is really a feature request. When a variable is unused (lets say
> some additional paths are introduced in the fitting process and a new fit
> without them is attempted), the choices in the parameter list are (fix,
> vary, and constrain). There is no option to “skip” like in Artemis.
> Obviously, one can choose fix, but in doing so the unused variable shows up
> in the fit result summary and is somewhat confusing. It would be
> subjectively better to have the option to “skip” a variable and not have it
> show up in the fit summary.
>

Another good point: Skip is a good option to have and doing "set to Skip"
instead of "set to Fixed" would be a reasonable thing for XAS_Viewer to do
for "unused parameters".  On the To Do list now!


>
> Just some initial thoughts...
>

Thanks very much!

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Athena: the R factor for normalized mu(E)

[Matt Newville]

Hi Jon Petter,

On Tue, Jul 12, 2022 at 12:46 AM Jon-Petter Gustafsson <
jon-petter.gustafs...@slu.se> wrote:

> Hello all,
>
>
>
> I have been a frequent user of Athena for many years, mostly for
> interpreting P K-edge XANES spectra. Until last week I thought that the R
> factor in Athena was always defined as:
>
>
>
> sum( [data_i – fit_i]^2 )
>
> ---
>
>sum( data_i^2 ]
>
>
>
> This is also the definition given in the online manual, and it has been
> stated by me and by other colleagues in a number of papers dealing with P
> K-edge XANES. But well, this is not true when dealing with normalized XANES
> spectra! I realized this when I played around with a number of my old LC
> fits in Excel. While the chi-square value (or maybe more precisely, the sum
> of squared residuals) was reproduced perfectly, I always got “R factors”
> (i.e. with the above definition) between 2 and 3 times lower than what
> Athena gives. After that I consulted the Demeter programming documentation (
> https://bruceravel.github.io/demeter/pods/Demeter/LCF.pm.html) to find
> that, for normalized mu(E), “Demeter thus scales the R-factor to make it
> somewhat closer to 10^-2”. However, the equation stated on this page
> actually reproduces the R factor even more poorly, and therefore I won’t
> reiterate it here.   After inspecting the Perl code, and trying out
> different alternatives in Excel, I now believe that the following equation
> provides a more accurate definition of the R factor (correct me if I’m
> wrong!):
>
>
>
> sum( [data_i – fit_i]^2 )
>
> ---
>
> sum( [data_i – avg data]^2 )
>
>
>
> where “avg data” is the arithmetic mean of the data in the LC fitting
> range. It would be great if others could confirm this. As far as I
> understand, this won’t affect the interpretations that any of us have made
> over the years, it only affects the understanding of what the R factor
> actually is…
>

Thanks, and yes, that does appear to be exactly what the Demeter code is
doing.  I never noticed that, or I guess it has honestly been a very long
time since I used Athena for linear combination fitting.   I'm not 100%
sure why it would do that when fitting normalized mu(E), but not
otherwise.

I agree that it will not alter the actual interpretation of whether one fit
is better than another.  It might be that some sort of "remove the most
obvious data trend" (often called "whitening") is a fine thing to do.

FWIW, linear combination fitting in Larch reports an R-factor that does not
subtract the average of the data in the denominator.  Maybe it should?
OTOH, one of the appealing features of the R factor is that it is meant to
be really easy to understand and reproduced.

Cheers,

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Larch 0.9.61 and 60

[Matt Newville]

Hi Kathy,

Thanks and sorry for the trouble.  I think I can reproduce this: changing
the definitions of Path Parameters is being ignored.   I have a theory of
what is going wrong, but I'll have to investigate this a bit...

On Tue, May 31, 2022 at 6:12 AM Kathy Dardenne 
wrote:

> Hello,
>
>
>
> I was trying to use Larch 0.9.59 to fit EXAFS Data. There was no
> possibility to save work in progress but it was possible to do fit, change
> name of the variable used and define the expression for amplitude (default
> defined as “n*s02” in Larch where n is taken from the feff calculation).
>
> I have 6 slightly different Cf-O distances in my model structure and took
> only one path, changing the amplitude definition “1.0 * s02” by “NO * s02”
> . this worked perfectly.
>
>
>
> However in Larch 60 and 61 where, thanks a lot!!!, we can now save our
> work,  it is not possible any more to change anything in the path parameter
> (neither name or expression). The added variable is not any more varied and
> not taken into account. Independently of the amplitude definition s02 get
> the same value as default definition and new variables stay by start value
> having no influence on the fit.
>
>
>
> I join some screenshot as well “Path parameters” and “Fit script”. Looking
> at the Path parameter I saw that the amplitude is still by default
> definition so no wonder that it acts without taking into account changes.
> This is the same for name changes.
>
>
>
> Am I the only one having trouble now? I worked till now with artemis,
> ifeffit and previously feffit soI do not have a big experience with Larch.
> The old feffit based versions stop all by Pu (Z=94) and I need Z=98 so I
> changed to Larch but need to get used to.
>
> I am using Larch in anaconda3 on a Win10 Computer.
>
>
>
> Thanks a lot for your help.
>
>
>
> Kind regards
>
>
>
> Kathy
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@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] Larch 0.9.61

[Matt Newville]

Hi Folks,

It's only been a few days, but there were some fairly important bugs and
misfeatures found with Larch 0.9.60.  Rather than wait, these have mostly
been fixed (details at
https://github.com/xraypy/xraylarch/releases/tag/0.9.61).   You can either
update the code yourself with `pip install --upgrade xraylarch`,  with the
binary installer, or by allowing XAS Viewer to run its updater.

Bug reports, comments, and suggestions are always welcome.

--Matt
___
Ifeffit mailing list
Ifeffit@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] Larch 0.9.60

[Matt Newville]

Hi Folks,

Larch version 0.9.60 has been released.  It should now be installed by
default using all installation mechanisms, and you should see a notice to
update, perhaps the next time you run  XAS Viewer.

There are several bug fixes and feature improvements in XAS Viewer. This
version also adds some important new features to XAS Viewer and Larch.
These are described in a bit more detail at
https://github.com/xraypy/xraylarch/releases/tag/0.9.60
Briefly, the new features for XAS Viewer are:

1. Each data "Group" has a processing Journal, with a time-stamped history
of processing events.  This will document the main processing steps.

2. Many preferences for XAS Viewer can now be set program-wide and saved
for future sessions. Copying processing parameters between groups now works
better.

3.  A Session or Project file can now be saved at any time. This will
contain all the arrays for a Group and also include fitting models and
per-group fit histories for Pre-edge Peaks, Linear-Combination analyses,
Feff-fitting (including Feff Paths), and so on.  These Session files can be
read back in and fit models and histories are restored in XAS Viewer. That
is, these files are intended to be suitable for exchanging by email and
archiving, etc.  Session files are also "auto-saved" periodically and can
be used to recover the last session on startup.

There are several changes here.  I'm confident with the basic functionality
and have been testing myself on all platforms.  But GUI actions are hard to
test thoroughly, so it is reasonable to expect some new bugs or
misfeatures.  With upcoming workshops in July, I expect to need a release
focused on bug and feature fixes in about a month.  So, I hope you will be
able to test and make any suggestions, comments, or error reports.

Cheers,
--Matt

PS: For Python users, all of Python 3.7, 3.8, 3.9, and 3.10 should work,
though the main installers are still using either Python 3.8 or Python 3.9.
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] structure for reference Mn foil

[Matt Newville]

Hi Yang,

On Thu, May 12, 2022 at 1:29 PM Hu, Yang (HIU)  wrote:

> Dear IFEFFIT members,
>
>
>
> I have been trying to obtain the S02 value from metal reference foils
> measured at the beamline.
>

How was your sample Mn metal prepared?   Do you have verification that it
is metallic?

When you say "from metal reference foils measured at the beamline.", I
wonder if that might be the same kind of
"reference foil set" in the wooden jewelry box that we have at our
beamline.  Most of these are very good, while some (Pb) degrade over time.
Ours has one labeled "Mn" which is obviously a black powder, probably
sintered.  I've never tried to analyze that as BCC Mn and assumed it was
stable-ish, but not metallic.   But maybe someone else has tried that.

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Larch 0.9.59, problems with PCA

[Matt Newville]

Hi Stefan,

Very sorry for that. This will be fixed in the next version, which I'm
hoping to get out in the next week or so.

On Tue, May 10, 2022 at 8:45 AM Mangold, Stefan (IPS) <
stefan.mang...@kit.edu> wrote:

> Dear all,
>
> on 2 computers (Mac, Intel and ARM, newest version operating system) the
> PCA does not work. If I press "Build Model with selected groups“ on both
> computers and several different datasets, I only get „training model“ and
> nothing else happens. Absolutely nothing else changes within this tab
> inside XAS viewer.
>
> Best regards
>
> Stefan Mangold
>
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@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] XAFS 2022 reminders

[Matt Newville]

Hi Folks,

Another reminder for XAFS 2022:

The abstract deadline has been extended to Monday, April 25th, but with a
deadline of midnight Sydney time:  https://xafs2022.org

And, nominations for the IXAS awards are due May 1:
https://xrayabsorption.org/ixas-awards-2022/

Cheers,

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] [Ext] Larch 0.9.59

[Matt Newville]

Hi Carlo,

On Sat, Apr 2, 2022 at 5:51 PM Carlo Segre  wrote:

> Hi Matt:
>
>  My installation is a mix of Debian packages and pip3 installations.  This
> allows for more recent packages that are not in Debian.  The trick is to
> know which ones are needed.  I can try the Linux install with one of my
> virtual Debian machines.  That might be helpful.
>
>
Yeah, I've been trying to get to the point where pip can be used as much as
possible.  I think that for Linux, the only real complication (after "basic
Python3.7 or later") is wxPython.  If there is a Debian package for that
(and probably there are packages for the other "core scientific packages"
of numpy, scipy, matplotlib, h5py), then I think everything else should be
installable with "pip" or a recent Debian package.

At least that is the intention.  It would be good to test that out in
practice too.  I have not tried a "root install with python from the OS
distribution" on RH/Centos machines either, but it would be good to try
that on both RH/Centos and Debian.  I think we might even be able to
automate some of that testing with Github actions (which defaults to
ubuntu).

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Path output with feff8l

[Matt Newville]

Hi Shinichi,

Make sure your feff.inp file for Feff8 has

CONTROL 1 1 1 1 1 1
PRINT   1 0 0 0 0 3
EXAFS   20.0

and it will calculate the classic Feff.dat files.


On Sun, Apr 3, 2022 at 11:25 PM 西村 真一 
wrote:

> Dear all,
>
> I have used Larch ver 0.9.59/0.9.58 on Linux for XAFS data processing and
> analysis.
> The scripting features are pretty helpful in our study.
>
> In the EXAFS analysis, I met a strange behavior of a function.
> The feff8l function does not generate the "feff.dat" files like Feff6l.
> This behavior is different from that in the web document (13.7.1.2).
>
> What is the best way to import the paths from the output of feff8l?
> Or is there any way to generate the "feff.dat" files with feff8l?
>
> I will appreciate your help.
>
> Best wishes,
> Shinichi
> ———
> Shin-ichi NISHIMURA, Ph.D
> nishim...@chemsys.t.u-tokyo.ac.jp
>
>
> Atsuo YAMADA Group,
> Department of Chemical System Engineering,
> Graduate School of Engineering,
> The University of Tokyo
>
> Yamada Lab., Engineering Bldg.#3-5C08,
> 7-3-1 Hongo, Bunkyo-ku, Tokyo, 113-8656,
> Japan
>
>
>
>
> ___
> Ifeffit mailing list
> Ifeffit@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
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] [Ext] Larch 0.9.59

[Matt Newville]

Hi Carlo,

On Fri, Apr 1, 2022 at 5:39 PM Carlo Segre  wrote:

> Hi Matt:
>
> I have managed to figure out an installation procedure using Debian Linux
> that installs Larch for all users on the system to use.  If this is useful
> for you , I can write it up.
>
>
Yes - I think that would be very helpful. I know that it's all pretty
focused on "install for an individual user", so if installing to a server
needs modifications, that would be interesting to either automate or at
least document.   For sure, we're trying to get to "normal pip
install-able", but wxPython on Linuxes makes that kind of challenging.

Somewhat related: I did verify that the Linux installer works for me, but I
built it on a Centos7 machine and installed it on a Centos8 machine, so
that might not be a fair test.  And I believe that some of the ESRF folks
had some trouble with debian and an earlier version of this installer.

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] XAFS 2022: important deadlines

[Matt Newville]

On Fri, Apr 1, 2022 at 4:47 PM Robert Gordon  wrote:

> Matt's idea of an April Fool's joke no doubt...
>
> The XAFS2022 website indicates that the abstract deadline is April 17.
>

Thanks, Robert!

And, just a regular fool ;).

--Matt
___
Ifeffit mailing list
Ifeffit@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] XAFS 2022: important deadlines

[Matt Newville]

Hi Folks,

... and some reminders:

Abstracts for XAFS 2022 are due April 19.  Please submit a presentation for
your work!  https://xafs2022.org

Nominations for the International X-ray Absorption Society Awards are due
May 1.  See
https://xrayabsorption.org/ixas-awards-2022/ for details.

--Matt
___
Ifeffit mailing list
Ifeffit@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] Larch 0.9.59

[Matt Newville]

Hi Folks,

Larch version 0.9.59 has been released.  It should now be installed by
default using all installation mechanisms, and you may see a notice to
update if running xas_viewer.

This is mostly bug fixes, but some are important enough to warrant pushing
out now.  Changes are detailed at
https://github.com/xraypy/xraylarch/releases/tag/0.9.59

For XAS Viewer use, the most important of these are
 a)  "energy reference" and "energy shifting" of spectra work much better.
 b) the action of the "pin icon to select points on the graph" has now
changed (by popular opinion) to be: click on pin icon, *and then* cliick on
point of the graph.

There are also new binary installers - the one for Linux might work for
more people ;), and the installation might be faster for more people.

We're hoping that there will be another release in a couple of months to
give a more comprehensive "Project File" concept.   But, as always,
suggestions or comments are welcome.

Cheers,

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Question related to save fitting results in Larch

[Matt Newville]

Hi Harry,



On Thu, Mar 24, 2022 at 11:30 AM Andy Zhang  wrote:

> Dear Sir/Madam,
>
> I have a question related to saving fitting results in Larch. I wonder if
> it is possible to save the project file with fitting results, just like the
> .fpj file in Artemis. In this way, I could save the partially finished work
> and do it later.
>

At the moment, there is not a "save as feff fitting result as a project"
that can be read back in.  You can save a script of the feff fit and edit
and run that.  But, XAS Viewer won't read that back in a way that can
reproduce the GUI experience.   And, it is much harder to share that as a
single "project" with others (including yourself in a week, or month, or
three years).   This is a "known problem" and one that we're trying to
figure out how to do well.

The current thought (but not set in stone) is to create a single project
file that encapsulates all the possible analysis types (pre-edge peaks,
linear combinations, feff fitting) into a single project file, probably
hdf5.

There isn't really a timeline for this, but we do know it is an important
need.

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Larch install error on MacOS 12.2

[Matt Newville]

Hi Stefan,

I hope it's kind of obvious,  but telling us "it doesn't work" is not going
to ever get a reply other than "follow the instructions and report back any
errors you may get".  You have not given us any error messages.

What do you mean by 'larch -m' did not work?  Did it give any error
messages?  If so, what were they?  If not, why didn't you say that?
When you installed with 'GetLarch.sh', what does the log file say about its
installation?

Did you try opening a Terminal and running
 ~/xraylarch/bin/xas_viewer

? If so, what does that report?

On Thu, Feb 10, 2022, 4:26 AM Mangold, Stefan (IPS) 
wrote:

> Dear Matt,
>
> sorry for the delayed feedback, my time for testing is pretty limited.
>
> 1. tried to start the old installation, but XAS viewer didn’t start
> 2. installed binary installer and tried to create new ICONs, didn’t work
> (used all command described on the webpage)
> 3. Install via script on the web page, installer said everything fine,
> start-up icons (XAS-viewer) created, but they didn’t start up.
>
> so next thing I will do is to install anaconda again, and try it via the
> instruction Jeff Terry pointed to
>
> ——
>
> # Create new environment
> conda config --add channels conda-forge
> conda create -n exafs python=3.7
> conda activate exafs
>
> # Install Conda Dependencies
> conda install -y "numpy=>1.20" "scipy=>1.5" "matplotlib=>3.0"
> scikit-learn pandas
> conda install -y pyparsing pytest pytest-cov coverage
> conda install -y h5py pillow  sqlalchemy psutil pyyaml
> conda install -y psycopg2-binary numdifftools emcee
> conda install -y wxpython
> conda install -y pymatgen
> conda install -y cython
>
> # Install lmfits and Xraylarch using Pip
> pip install lmfit peakutils pyepics pyshortcuts termcolor sphinx dill
> pycifrw xraydb wxmplot wxutils
> pip install xraylarch
>
> larch -m
>
>
> 
>
>
> more testing probably this evening …
>
> best regards
>
> Stefan Mangold
>
>
> > Am 09.02.2022 um 22:59 schrieb Matt Newville  >:
> >
> > Hi Stefan,
> >
> > Sorry for the trouble.  I would definitely recommend deleting and
> starting over with the binary installer.  If you run into trouble with
> that, running the "GetLarch.sh" in a Terminal would probably be the most
> helpful, as it will create a log file that might have some clues about what
> went wrong.  And, like Jeff said, if you don't get the Larch folder of
> Apps, typing
> >~/xraylarch/bin/larch -m
> >
> > in a Terminal should remake those.
>
>
>
> >
> >
> > On Wed, Feb 9, 2022 at 2:05 AM Mangold, Stefan (IPS) <
> stefan.mang...@kit.edu> wrote:
> > Dear all,
> >
> > I upgraded a machine to 12.2 (MacPro), Larch was installed via binary
> installer. Afterwards Larch didn’t launch. I did a re-install with the
> binary installer and this didn’t work, because already installed. deleted
> it, but this also didn’t work
> >
> > tried
> >
> > pip install xraylarch
> >
> > stopped
> > with
> > ERROR: Failed building wheel for fabio
> > Failed to build fabio
> >
> > also no director with XAS viewer created.
> >
> >
> > best regards
> >
> > Stefan Mangold
> >
> >
> > --
> > --Matt Newville  630-327-7411
>
>
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Larch install error on MacOS 12.2

[Matt Newville]

Hi Stefan,

Sorry for the trouble.  I would definitely recommend deleting and starting
over with the binary installer.  If you run into trouble with that, running
the "GetLarch.sh" in a Terminal would probably be the most helpful, as it
will create a log file that might have some clues about what went wrong.
And, like Jeff said, if you don't get the Larch folder of Apps, typing
   ~/xraylarch/bin/larch -m

in a Terminal should remake those.


On Wed, Feb 9, 2022 at 2:05 AM Mangold, Stefan (IPS) 
wrote:

> Dear all,
>
> I upgraded a machine to 12.2 (MacPro), Larch was installed via binary
> installer. Afterwards Larch didn’t launch. I did a re-install with the
> binary installer and this didn’t work, because already installed. deleted
> it, but this also didn’t work
>
> tried
>
> pip install xraylarch
>
> stopped
> with
> ERROR: Failed building wheel for fabio
> Failed to build fabio
>
> also no director with XAS viewer created.
>
>
> best regards
>
> Stefan Mangold



-- 
--Matt Newville  630-327-7411
___
Ifeffit mailing list
Ifeffit@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] post-doc opportunity

[Matt Newville]

Hi Folks,

I'd like to pass on this advertisement for a post-doc position at U
Illinois at Urbana Champaign:


Post-doctoral researcher, Dept of Geology, University of Illinois Urbana
Champaign: XAS study of molecular complexation of PGE sulfides in high
temperature and pressure geological fluids

Applications are invited for a postdoctoral researcher position in the
Department of Geology (School of Earth, Society and the Environment) at the
University of Illinois at Urbana Champaign. We seek a person with strong
background in high-temperature hydrothermal/magmatic liquids and
experimental geochemistry to perform EXAFS and XANES analyses on both
glasses and solutions produced in high temperature and pressure laboratory
experiments.  The goal is to determine the solubilities and understand the
molecular complexation of PdS and PtS in hydrous alkali silicate and
carbonate liquids. Experience and knowledge of synchrotron XAS analyses are
required. Skills in performing experiments at high pressure and temperature
as well as advanced knowledge of chemical thermodynamics and computational
geochemistry are all preferred qualifications. The postdoc will have
opportunities to participate in interdisciplinary research involving
aspects of geoscience, chemistry, and material science.

Requirements and qualifications include:

PhD in mineralogy, chemistry, material science, or closely related field.
Prior experience with synchrotron X-ray spectroscopy/scattering/microscopy
techniques is required. Familiarity with other analytical techniques such
as SEM-EDS, XRD, and ICP-MS is highly favorable.
Prior experience with high pressure experimental geochemistry is preferred.
Excellent oral and written communication skills

This position is part of a new collaborative project between UIUC (PI C.
Lundstrom), Johns Hopkins University (Co-PI D. Sverjensky), and University
of Chicago (Co-PI G. Gauli). This project is funded by the Department of
Energy (DOE) Basic Energy Sciences under the critical minerals and
materials program (https://www.energy.gov/articles/doe-awards-
30m-secure-domestic-supply-chain-critical-materials).

The selected candidate would start in late Spring 2022 at UIUC. XAS
analyses at Argonne/APS would likely start in summer 2022 and occur through
April of 2023 when the APS beamline shuts down. For the remainder of 2023
and 2024, XAS work using a pressurized hydrothermal cell is planned to
occur at Grenoble/European Union Synchrotron facility.

The initial appointment is for one year with possible renewal for another
1.5 years upon mutual satisfaction. Interested individuals should submit a
single pdf file that includes: 1) a cover letter that outlines the
applicant's research, expertise match to the position, and career goals; 2)
curriculum vitae; 3) copies of representative recent research publications;
and 4) contact information of three references, electronically to Prof.
Craig Lundstrom, lunds...@illinois.edu. Review of applications will begin
January 25, 2022. UIUC is an Equal Opportunity/Affirmative Action employer,
and applications from women and under-represented minorities are
particularly encouraged.--


--Matt Newville
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] FEFF calculation on ferri-/ferrocyanide materials

[Matt Newville]

Hi Yang,


On Sun, Jan 23, 2022 at 11:30 AM Hu, Yang (HIU)  wrote:

> Dear IFEFFIT members,
>
>
>
> I am trying to apply the FEFF calculation on Metal-[Fe(CN)6] type
> materials (in Larch). The calculations were successful with cif files from
> (K, Na)x(Cu, Ni) [Fe(CN)6]  for both C-coordinated Fe and N-coordinated
> metals, and their results include higher-order paths.
>
>
>
> However, the calculation on NaxFe[Fe(CN)6] always gives the warning “…Two
> atoms very close together. Check input…” and takes long time. The
> calculated results have some collinear 5- and 6-leg paths with several
> hundred or even thousand importance value.
>
>
>
> I am wondering if it is possible to limit the multiple scattering to a
> lower order in the calculation (such as suggested in Artemis user guide).
>
> Plus, if I only aim to model the nearest Fe-C and Fe-N for its Fe K-edge
> spectra, are there any alternative methods for the calculation? — I also
> would like to ask whether it is meaningful to do this while ignoring those
> multiple scatterings in this type of materials.
>
>
>

I'm not sure why those (or one of them?) is reporting "atoms too close
together".
You can control "how far out to go in R" with "RPATH" - is a value that is
smaller than the cluster size.
That is, you could use something like

RPATH 5.25

to consider paths with distance (half-path lengths) up to 5.25 Ang.

You can use NLEG to set the maximum number of legs in a
mulltiple-scattering path. That is,

NLEG 2

would mean "single scattering only", but you might want to actually use 3
or 4.  The default is 8 (in Feff8 that is, it is 7 with Feff6).

Cheers,

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Question_Demeter installation on Mac with Apple Silicon M1

[Matt Newville]

Hi Maolin,

On Thu, Jan 20, 2022 at 11:13 PM 王茂林  wrote:

> Dear IFEFFIT members,
>
>
> Here I want to install Demeter in my Mac with M1 pro, I followed the
> processes in 
> *https://bruceravel.github.io/demeter/documents/SinglePage/macinstallation.html
> *
> (First, install Xcode and Xcode command tool; Then install Macport). But
> when I type "
>
> sudo port install xorg-server demeter
>
> in the terminal and after agreeing to the terms, there came to a warning,
> shown in the attached figure. What should I do to install it on my mac? And
> the log file (also attached) seems like Demeter doesn't support the M1 with
> ARM architecture?


I'm not surprised that there is not a MacPorts port to MacOS M1/ARM yet.
As it turns out, I'm still waiting (7+ weeks!) for the delivery of an M1
Macbook Pro. I have not built any of the compiled binaries or libraries
used by Larch (say, Feff, or reading XDI file) for M1/ARM yet myself (or
tried to configure any build farms to do so).

FWIW, there was a bit of discussion on the MacPorts version of this
software:
https://millenia.cars.aps.anl.gov/pipermail/ifeffit/2021-November/010334.html

The message there (perhaps not a "conclusion") was that supporting Demeter
and Ifeffit on macOS is very hard.

Just to be clear, the error you see is with PGPLOT, last released in 2001
(sic).  Ifeffit (last release in 2010, bug fixes until 2014) never required
PGPLOT - it was optional.  Demeter (last release 2018) never used the
PGPLOT functionality.  For sure, porting of these tools would be easier if
PGPLOT was left out entirely, but porting code that is no longer being
developed or supported is going to be an endless chore for someone. And as
it turns out Perl+Wx+MacOS has always been extremely challenging and it
appears that no one is working on it (wxPerl last released in 2017, for any
system).

Basically, I think that no one is going to work very hard on getting
Demeter to work on macOS M1. It might be a good opportunity to try out the
alternatives.

--Matt
___
Ifeffit mailing list
Ifeffit@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] Larch 0.9.58

[Matt Newville]

Hi Folks,

Larch version 0.9.58 has been released.  It should now be installed by
default using all installation mechanisms, and you may see a notice to
update if running xas_viewer.

Coming only 6 weeks after 0.9.57, and with the holidays in between, this is
mostly a set of bug fixes, especially surrounding installation and errors
associated with our use of deprecated features of silx and numpy.Thanks
mostly to Mauro for this, and for updating the documentation for
installation, especially for existing Anaconda Python users, and on Linux.

FWIW, I checked that a fresh install works on Windows 10, MacOS 12, CentOS
7, CentOS 8 Stream, and that "auto-updates" work with "larch -u" or from
XAS Viewer works on MacOS 12 and on Fedora 34.  But, of course, let us know
if you have suggestions, comments, or problems.

There are a few fixes for reading some kinds of data files and with
de-glitching XAS spectra.  The plans discussed in the previous release
message (see
https://millenia.cars.aps.anl.gov/pipermail/ifeffit/2021-December/010345.html)
about saving more complex projects and how to think "reference spectra"
have not had much work done on them.  The request for suggestions and
comments on these topics still stands.

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] How do I launch Larch GUIs?

[Matt Newville]

Hi Betsy,

Very sorry for the trouble and delay.  I feel like my email signature
should be
"Sorry for the late reply.  Zoom Meetings, Proposal Writing, and doom
scrolling the NY Times Covid Page have prevented me from doing real work
for the past year"

On Mon, Jan 10, 2022 at 2:59 PM Swanner, Elizabeth S [GE AT] <
eswan...@iastate.edu> wrote:

> I use a Mac recently updated to Big Sur (11.6). I used the Binary
> Installer File for Larch and am a little stuck on what to do next. I was
> able to run the installer, and I have an xraylarch folder on my computer.
> However, I was hoping to use the XAS Viewer and do not see it within the
> folder. Should it be there? I had an old version of XAS Viewer I got while
> at APS but needed to replace that as it did not have all the modules. I did
> not check before removing that whether it was working on this OS.
>

It *should* be that there is a desktop folder called 'Larch' that has Apps
in it, including for "XAS Viewer".
There will also be a folder in your home directory called "xraylarch" with
all the code in it.

If you ran the installer but don't have the 'Larch' desktop folder, or if
something went wrong, you should be able to open a Terminal and type

  ~/xraylarch/bin/larch -m

at the prompt to make the Larch folder and mini-Apps to launch.   If
something goes wrong, that should report an error (if so, please send
that!).

With the Terminal open, you should also be able to type

~/xraylarch/bin/xas_viewer

to launch XAS Viewer -- that's basically what the desktop app does.  Again,
if something goes wrong, that will report a readable error.  (and if so,
please send that!)

There have been recent reports from others of broken installations because
of problems with our use of the packages called "silx" and "numpy".  These
are fixed in the development branch, but I may need to push out a new
version.  I was hoping to finish some features, but maybe the fixes should
be pushed out today or tomorrow.


>
> I am also not clear how to use Larch in general (i.e., the Basic Larch
> GUI). Do I need to install python? I see there is a python application in
> the folder but when I try to open that nothing happens. I’m not sure if
> these are issues with my OS or if I am missing something really basic about
> how to launch Larch.
>

The intention is that you can use the XAS Viewer GUI and do not need to use
the basic Larch GUI or Python unless you want to (and some people do!) or
are going down the route of "okay, I really need to do some batch
processing". The  "HOME/xraylarch" folder includes a complete python +
tools installation and will allow that.
But, the GUIs should work!

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Problem in xrayLarch installation

[Matt Newville]

Hi Latif,

Sorry for the trouble.  As Mauro said, some of the packages needed (and
pymatgen is one of these) are not super-well supported for installing with
pip.

FWIW, I agree that the needed combination of conda and pip is sort of
unfortunate.  But most of the "problem packages" are either Windowing
systems (wxPython: that have been challenging to have consistent binary
support on Linux is very challenging) or packages of scientific code
written by and for scientists, some with excellent engineering support and
some (like us!) with "less" support.   Conda is a popular option for many
of these.  We try to support the simpler / more ubiquitous pip where we
can.

Anyway, that's basically why we have the binary installers and installation
scripts.  But also: thanks for the report and we are trying to clean up or
at least document some of these kinds of issues where we can:
https://github.com/xraypy/xraylarch/issues/333

--Matt
___
Ifeffit mailing list
Ifeffit@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] Larch 0.9.57

[Matt Newville]

Hi All,
Larch version 0.9.57 has been released and is available on PyPI (
https://pypi.org/project/xraylarch).  It should now be installed by
default using most installation mechanisms, and you may see a notice to
update if running xas_viewer.

The updates are described in some at
https://github.com/xraypy/xraylarch/releases/tag/0.9.57
and in the github commit history.  This includes adding support for reading
RIXS data files from ESRF BM16, better support for de-glitching in
XAS_Viewer, and fixing of reading of many Athena Project Files that were
saved in the "old style" and have non-ASCII characters (the code now
correctly reads the 78 Project files at
https://github.com/xraypy/xraylarch/tree/master/examples/xafsdata/AthenaProjectFiles
).

Much of the work for this release has come from Mauro Rovezzi. In a
conversation we had yesterday about this release, we talked about several
potential changes going forward, especially for XAS_Viewer, about saving
processing history, how to improve the concept of "reference spectrum" for
a measurement, and other topics related to keeping track of analysis
history and provenance.  Some of these ideas are encapsulated in Github
Issues at https://github.com/xraypy/xraylarch/issues, and the plan is to
work on this.  One possibility would be to be able to read and export to
Athena Project files but use a different format (probably HDF5) as a new
default "Larch Project File" so that more complexly nested data and some
sort of "journal" per data set could be saved, displayed, edited, and so
on.

If anyone here has some thoughts on how such topics could or should be
handled, please let us know.  If you have other ideas on what might be
added or improved, also don't hesitate to speak up, either in conversations
here or on Github.

Cheers,

--Matt Newville
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Fe and Ni carbide XAS reference spectra?

[Matt Newville]

Hi Valentijn,

For Fe3C, see https://xaslib.xrayabsorption.org/spectrum//105/

I'm not sure what "does not contain the Energy values of the spectrum"
means.


On Mon, Nov 15, 2021 at 3:10 AM Valentijn De Coster <
valentijn.decos...@ugent.be> wrote:

> Dear ifeffit mailing list,
>
>
>
> My name is Valentijn De Coster. I am a PhD student at Ghent University,
> Belgium, working on Ni and Fe materials for CO2 utilization.
>
>
>
> I am currently looking for Fe and Ni carbide (Fe3C, Ni3C) reference XAS
> spectra, at the respective Fe K and Ni K edges, for fingerprinting
> purposes. As such, I was wondering whether anyone would have such data
> available.
>
>
>
> On a side note, I checked the CARS database, and while this has an Fe3C
> (Fe K edge) reference, the data file does not contain the Energy values of
> the spectrum.
>
>
>
> Thank you in advance for your time.
>
>
>
> Kind regards,
>
> Valentijn De Coster
>
>
>
> [image: Image result for ghent university logo]
>
> *Valentijn De Coster*
>
> *PhD Student*
>
> *Laboratory for Chemical Technology (LCT) *
>
> Department of Materials, Textiles and Chemical Engineering
>
> Technologiepark 125, 9052 Ghent, Belgium
>
> T: +32 9 331 17 M: +32 (0) 331 17 10
>
> https://www.lct.ugent.be   https://helpdesk.UGent.be/e-maildisclaimer.php
> 
>
> Member of CSC: https://www.csc.ugent.be
>
>
>
>
> ___
> Ifeffit mailing list
> Ifeffit@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
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] MacPorts XAFS software: announcing a Port for Larch; and do we actually need Demeter on Macs?

[Matt Newville]

Hi Joseph,

First, thanks very much for doing this.  I know that it is a lot of work,
and you really only hear when it doesn't work perfectly.  So, thanks!

Second, please keep working on those TES detectors!  We need those too!

On Demeter:  I sort of think the reality is that it is just too difficult
to maintain Demeter running natively on MacOS.  If MacPorts can't do it, it
probably cannot be done.  Larch XAS Viewer might be a viable alternative
(at this point, I would say calling anything that  XAS Viewer does not do
that Demeter does is probably a bug or missing feature in XAS Viewer, or at
least fair to discuss in those terms), or running Demeter on Windows
(either a different machine or in a virtualization tool like Parallels) is
a reasonable expectation.

So, I would probably lean toward your option #1: declare these ports dead.
I doubt that #2 (wait for Perl) is likely to be any better over the
next couple of years compared to the past couple of years.

Again, thanks,

On Thu, Nov 11, 2021 at 9:18 AM Fowler, Joseph W. (Assoc) <
joe.fow...@nist.gov> wrote:

> Hello XAFS fans:
>
> This note is about the Demeter package on MacPorts. If you don’t use
> Demeter through MacPorts on a Mac, skip this note.
>
> I’m the MacPorts “maintainer” of the ports demeter and ifeffit. They have
> been not installable or upgradeable for something like a year, because of
> new releases of … something?  Probably either Mac OS X, and/or Apple's
> Xcode development system. I’ve made a ton of progress on my big goal of
> restoring demeter to life, but I cannot get all the way to finish the
> project.
>
> I have to say here that I’m a poor choice to maintain these ports. I
> barely understand how MacPorts works, and I don’t understand or use Perl at
> all. I am not even really an x-ray scientist—I develop superconducting
> x-ray sensors in a team at NIST, and I happened to be a collaborator of the
> previous maintainer when he left the field 6 or 8 years ago.
>
> I worked on the problem in two parallel paths. One was to create an
> official port for the Python package Larch. Late last month this was
> complete, so you can do a “sudo port install py39-xraylarch” and have it.
> (Replace “py39” with “py38” or “py37” if you use Python 3.8/3.7.)  This
> required creating about a dozen new ports for Larch’s dependencies.
> (Actually, I know a ton more about how MacPorts works than I did six weeks
> ago.) Some new ports that might be of interest to this community include:
>
>- py39-pymatgen
>- py39-peakutils
>- py39-xraydb
>- py39-spglib
>- py39-xraylarch
>
>
> My other path was to track down and fix the problem that prevented ifeffit
> from compiling. (Recall that this package is unmaintained since 2014. See
> https://github.com/newville/ifeffit/). It looks like Xcode’s C compiler
> recently turned the “implicit function warning” into an error. A few hours
> ago, MacPorts accepted my proposed patches, so at least ifeffit should be
> installable as a port again.
>
> Unfortunately, demeter still won’t install completely, owing to problems
> in certain Perl-based ports that it depends upon, like p5.30-wx. That
> problem is so far from my expertise that I am completely stuck. I had hoped
> that if I got ifeffit to work, demeter would follow, but I was wrong.
>
> There are four strategies I can imagine from here:
>
> 1. Declare the ports ifeffit and demeter to be obsolete. Mac users will
> need to figure out other ways to do what Athena and Artemis do.
> 2. Wait until Perl experts fix the Perl dependencies (expect it to take
> months or more), then I fix demeter.
> 3. Modify/migrate Demeter so that Athena and Artemis rely completely on
> Larch and not at all on ifeffit.
> 4. Ask this mailing list for advice.
>
> I don’t know what strategy #3 would entail—again, I know zero Perl and
> don’t use this software. Demeter’s author told me he doesn’t have much
> interest in this upgrade. All I can really support alone is strategy #1 or
> #2: obsoleting or waiting.
>
> And that’s why I’m writing. On one side, does anyone care if
> Athena/Artemis become unavailable through MacPorts? So, does anyone object
> to path #1? On the other, does anyone here have better ideas?
>
> Best wishes,
> Joe Fowler
> NIST Boulder Labs
> ___
> Ifeffit mailing list
> Ifeffit@millenia.cars.aps.anl.gov
> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
> Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit
>


--Matthew Newville  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Problem in installing Larch

[Matt Newville]

Hi Raheleh,

Sorry, this has been seen a few times now, and "just" needs a new release
of xraylarch posted. I hope to do this within a day or so.

Cheers,


On Wed, Oct 20, 2021 at 9:11 AM Daneshpour, Raheleh  wrote:

> Hello!
>
>
>
> I am Raheleh a PhD student at Penn State working in FeNi catalysis and
> using XAS. I am trying to install the Larch, but I constantly get an error
> message on different computers and using different installation methods.
> The attached file is a screenshot of the error message I got. Could you
> please help me to figure out how to solve the problem?
>
> Thanks,
>
> Raheleh
>
>
>
> *Raheleh Daneshpour (She/Her)*
>
> Ph.d. student
>
>
>
> Email: rmd5...@psu.edu
>
>
>
> Chemical engineering department
>
> The Pennsylvania State University
>
> University Park, PA
>
>
>
>
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Bug report: Athena, multiple data export

[Matt Newville]

Hi Soyoung,

On Fri, Oct 8, 2021 at 5:29 PM Soyoung Kim  wrote:

> I see. Thank you for the quick reply.
>
> But would it be difficult to program it so that it will export properly,
> e.g., with multiple energy axes?
>

Sorry for the slight delay, and I have two answers here:

In general, it depends on what "export properly" means. If you save the
project file, the original, differing energy arrays will be retained.  If
you export to a simple ASCII column file (which is pretty ubiquitous in
scientific data), then each numeric row will be (or perhaps "is likely to
be") interpreted as the same "x" axis (energy or perhaps time - the
independent variable).   So, if you have multiple sets of data with
differing x/energy values, either you have missing values for some data
sets or you have data in rows without a consistent x/energy, and possibly a
different number of rows per column.  Many programs will struggle with such
data files.

But

Because when the data is plotted as a graph, it is hard to tell whether or
> not the x-axes are the same... And if you are processing data from someone
> else, you may not know whether or not they were collected with the same
> energy step settings.
>

That's all true.

And also: it looks to me that the exported data from this project looks
like it is not interpolated as well as it could be. There is a definite
shift in energy in the EXAFS region.

If I read that project into Larch's XAS Viewer and export it as a CSV file
it also interpolates all arrays onto a single energy grid (by default, the
first data set) and it looks better to me (see attached file -- needs
development version of XAS Viewer for this level of details).

I'm not entirely sure where the problem is. It does look like one of the
data sets has two energy points that are very close together as the data
transitions from constant energy steps in the XANES region to wider steps
in the EXAFS region.  That should not cause a problem, but I think that I
do recall that there were some such problems in the past.

We've tried to make XAS Viewer a replacement for Athena and Artemis.   I am
aware of a few missing features, but there are also several features not in
Athena.  I can say that it would be easier for me to fix things with
Larch/XAS Viewer than it is for me to fix things in Athena.

I'm not sure that resolves the issue, but I hope it helps.

--Matt
# 2 files saved Sun Oct 10 23:05:24 2021
# saving x array='energy', y array='norm'
# data1: data1
# data2: data2
#--
# energy data1 data2
4815.00 0.001453 0.001690
4825.00 0.000822 0.000912
4835.00 0.000460 0.000493
4845.00 0.000130 0.96
4855.00 -0.000157 -0.000221
4865.00 -0.000333 -0.000342
4875.00 -0.000527 -0.000602
4885.00 -0.000622 -0.000622
4895.00 -0.000661 -0.000545
4905.00 -0.000571 -0.000717
4915.00 -0.000355 -0.000431
4925.00 -0.000194 -0.000183
4925.25 -0.99 -0.90
4925.50 -0.000137 -0.26
4925.75 -0.35 -0.000216
4926.00 -0.000138 -0.93
4926.25 -0.87 -0.57
4926.50 -0.22 -0.000131
4926.75 -0.73 -0.43
4927.00 -0.54 -0.15
4927.25 -0.77 0.22
4927.50 -0.22 -0.22
4927.75 -0.31 -0.60
4928.00 0.07 -0.000111
4928.25 -0.07 -0.12
4928.50 0.24 0.000120
4928.75 0.000129 0.000133
4929.00 -0.27 -0.31
4929.25 0.21 0.000126
4929.50 0.02 0.000102
4929.75 0.000175 0.000146
4930.00 0.000181 0.98
4930.25 0.000120 0.62
4930.50 0.99 0.000182
4930.75 0.000149 0.000302
4931.00 0.000140 0.000247
4931.25 0.000149 0.000169
4931.50 0.000265 0.52
4931.75 0.000187 0.000186
4932.00 0.000163 0.000254
4932.25 0.000161 0.000328
4932.50 0.000337 0.000265
4932.75 0.000267 0.000309
4933.00 0.000241 0.000317
4933.25 0.000353 0.000428
4933.50 0.000349 0.000468
4933.75 0.000313 0.000472
4934.00 0.000357 0.000432
4934.25 0.000413 0.000417
4934.50 0.000348 0.000373
4934.75 0.000435 0.000430
4935.00 0.000430 0.000403
4935.25 0.000445 0.000549
4935.50 0.000517 0.000485
4935.75 0.000496 0.000453
4936.00 0.000496 0.000410
4936.25 0.000550 0.000529
4936.50 0.000471 0.000627
4936.75 0.000556 0.000605
4937.00 0.000647 0.000682
4937.25 0.000623 0.000636
4937.50 0.000681 0.000806
4937.75 0.000688 0.000709
4938.00 0.000734 0.000610
4938.25 0.000726 0.000498
4938.50 0.000648 0.000657
4938.75 0.000665 0.000524
4939.00 0.000747 0.000738
4939.25 0.000834 0.000892
4939.50 0.000810 0.000900
4939.75 0.000880 0.000767
4940.00 0.000882 0.000733
4940.25 0.000857 0.000880
4940.50 0.000916 0.000922
4940.75 0.000795 0.000897
4941.00 0.000997 0.000900
4941.25 0.000984 0.001074
4941.50 0.000967 0.000955
4941.75 0.001034 0.001153
4942.00 

Re: [Ifeffit] S02 selection from reviewer

[Matt Newville]

Hi Peng,

On Sat, Oct 2, 2021 at 2:50 AM Peng Liu  wrote:

> Dear IFEFFIT members,
>
> I am sorry to bother you again. I asked about S02 selection for the first
> major revision. I just received the second revision. The reviewer is not
> satisfied with one S02 value for all our samples.
> "
>
> 1. I am still not satisfied with selected SO2 value (it is set to 0.85).
> SO2 is not transferable between different samples and detection methods. It
> is not possible to use a value obtained from different compound using
> transmission measurement mode to completely different other compound
> measured using fluorescence mode. One method to fix SO2 value is to measure
> diluted solution (to avoid self-absorption) of reference material in
> fluorescence mode. Other is to use multiple spectra fitting for all samples
> of interest (e.g. with Sb(V)) measured using fluorescence mode where SO2
> parameter is the same for all samples.
>
> At the same time I am confident that CN values 5.6, 7.1 and 6.9 correspond
> to CN(Sb-O)=6. I suggest reconsidering the SO2 value for measurements in
> fluorescence mode.
> "
>
> We do get the S02 from a similar reference material measured in
> transmission mode, and our samples were all measured in fluorescence mode.
> It is not possible to measure the diluted reference material in
> fluorescence mode in one or two months. If you could give me some
> suggestions, that would be great.
>


It is always challenging to know what to do when a reviewer insists on
being wrong.   Well, I guess it is even more challenging when they turn out
to be right. ;).

Many different sample preparation and measurement effects can suppress the
overall XAFS amplitude.  There are "theoretical/calculational" terms:
 a) the relaxation of passive electrons to the core-hole that gives S02.
 b) the photo-electron mean-free-path.

that are expected to be "atomic only" and so will not vary with measurement
mode or sample-to-sample (mean-free path might be affected by samples
smaller than a few mean-free path lengths, but the evidence for this is
incomplete).  But, the calculations for these (at least from "easily run
XAFS calculations'') terms are imperfect and may need adjusting to
completely match experimental spectra.  For simplicity, we tend to adjust
S02 but not the mean-free-path.

There is also an amplitude term that may vary beamline-to-beamline (or even
between beam runs) but not between samples or measurement mode:
c) the actual energy resolution of the beamline.

This could be compensated by adjusting either the mean-free-path term or
S02.  Again, we typically just adjust S02.  In my experience, adjusting the
mean-free-path ("Ei" in ifeffit/Artemis/Larch) is not any better than
folding this into S02.   I'll also say that for the very common situation
of "Si(111) monochromator at a beamline intended for XAFS" especially in
the common 5 to 20 keV range, that spectral resolutions tend to be pretty
close to one another.

And there are terms that can reduce the amplitude that can vary from
sample-to-sample, and some of these are different depending on the
measurement mode.
   d) pinhole effects, important for transmission mode.
   e) over-absorption for fluorescence mode.
   f) detector saturation effects for fluorescence mode measured with
pulse-counting, energy-dispersive detectors.
   g) edge step from normalization, where slowly varying backgrounds can be
different for collection mode.

That is, if you have avoided or corrected for "d", "e", "f", and "g", then
S02 will be transferable between samples, at least those measured with the
same beamtime to account for "c".

All that said, I would expect the reviewer may be correct when saying "I am
confident that CN values 5.6, 7.1 and 6.9 correspond to CN(Sb-O)=6.",
especially if that is a main conclusion of the work.   It appears to me
that the reviewer may not be convinced that effects "e" and "f" were
completely avoided or compensated.

That is, claiming that the uncertainty in coordination number is less than
1 (and claiming that CN of 7 and 6 are significantly different) would
require special attention and confidence that the sample-dependent factors
were carefully addressed.   For example, if two transmission measurements
give CN of 7.1 and 6.9 (say with fitting uncertainty of 1) and a sample
measured in fluorescence measurement gives CN of 5.6 +/- 1, I think it
would be fair to suspect that the effects "e", "f", and "g" could be
influencing that difference.  If those effects are large, then you may need
to convince the gentle reader and the not-so-gentle reviewer that
corrections are done appropriately.

Hope that helps,

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] IFEFFIT file saving issue

[Matt Newville]

Shinhyo -

"Desktop" is almost certainly a folder under your user folder something
like "C:\Users\\Desktop" (unless you really went out of your way
to set something else up).  If your user name has non-ASCII characters,
that will not work.  Many people with laptops running Windows purchased
outside of the US and/or with non-ASCII characters (including Latin-1
characters that would be described as "accent characters" to folks in the
US) have seen this sort of problem.  It's a pretty common problem,
actually.
Also, just to be clear, it's not so much that people like Bruce and I are
unaware of the fact that many people's names include such characters, it's
that the software tools from even "only" 20 years ago really did not have
consistent support for characters that are not ASCII.

If you can save a file to a USB drive, you can probably save it to the
top-level "C:\" folder or any folder that contains only ASCII characters.

--Matt

On Tue, Sep 7, 2021 at 8:25 PM Bang, Shinhyo  wrote:

> Dear Matthew,
>
> I tried to save a project to "Desktop" which had no parent folder, but the
> same problem occurred. I think the non-ASCII character is not the only
> problem.
> Still, I can save onto a usb from now on. Thank you very much.
>
> Best,
> Shinhyo
> --
> *보낸 사람:* Matt Newville  대신 Ifeffit <
> ifeffit-boun...@millenia.cars.aps.anl.gov>
> *보낸 날짜:* 2021년 9월 7일 화요일 오후 6:06
> *받는 사람:* XAFS Analysis using Ifeffit 
> *제목:* Re: [Ifeffit] IFEFFIT file saving issue
>
> Hi Shinhyo,
>
> Again, I would ask to check that the folder you are having trouble saving
> to has any non-ASCII characters. For sure, ifeffit and demeter are not
> going to be able to handle folder or file names with non-ASCII characters.
>
> Larch is slightly better at this - it can work with files with names in
> non-ASCII text encodings.  To be clear, the situation with Larch is still
> not ideal, especially on Windows, because
>a) the base installation folder can contain only ASCII characters, and
> cannot contain any spaces (apparently this is some problem
>with other libraries or possibly some other variation on point b).
>b) the concept of "localization" on Windows machines is sort of a mess
> and many libraries (at least, from Python) don't handle this very well.
> For Larch, we recently had to explicitly set locale to be "simple C /
> ASCII".  That sort (or should!?) mean that you can read/write files and
> folders with non-ASCII characters, though I'm not certain that will work
> for all character encoding sets.  It's possible this will get better with
> time, but it's not something that we can solve.
>
> For ifeffit / demeter there is simply no hope for non-ASCII text to ever
> be handled.
>
>
> On Tue, Sep 7, 2021 at 7:45 PM Bang, Shinhyo  wrote:
>
> Dear Matthew,
>
> I tried to save the project onto a usb, and it WORKed! Thank you so much
> for your help.
>
> Best,
> Shinhyo
> --
> *보낸 사람:* Matthew Marcus  대신 Ifeffit <
> ifeffit-boun...@millenia.cars.aps.anl.gov>
> *보낸 날짜:* 2021년 9월 7일 화요일 오후 4:11
> *받는 사람:* ifeffit@millenia.cars.aps.anl.gov <
> ifeffit@millenia.cars.aps.anl.gov>
> *제목:* Re: [Ifeffit] IFEFFIT file saving issue
>
> There are other characters that Windoze doesn't like in filenames:
> |\/*":<>?
> mam
>
> On 9/7/2021 3:58 PM, Matt Newville wrote:
> > Hi Shinhyo, Liane,
> >
> > On Tue, Sep 7, 2021 at 5:39 PM Bang, Shinhyo  > <mailto:shinhyo.b...@wsu.edu >> wrote:
> >
> > Thank you for the response.
> > The OS is Windows 10.
> > In addition to the symptom that was described aforehand, Athena
> > freezes when I try to save the file.
> >
> >
> > Is it possible that the folder or file you are saving to has a space or
> > other non-ASCII character in it?  I believe that non-ASCII characters
> > are known to cause problems.
> > Can you check whether you can save a file anywhere (maybe even the
> > top-level "C:\" folder)?
> >
> > --Matt
> >
> > ___
> > Ifeffit mailing list
> > Ifeffit@millenia.cars.aps.anl.gov
> >
> https://urldefense.com/v3/__http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit__;!!JmPEgBY0HMszNaDT!_9MKQWuqA2MOuT45VXoI-3HKCOtMuCieGeTJVnN_NT2ZWYzBJuzUu-6yy1MIcPr5-UY$
> > Unsubscribe:
> https://urldefense.com/v3/__http://millenia.cars.aps.anl.gov/mailman/options/ifeffit__;!!JmPEgBY0HMszNaDT!_9MKQWuqA2MOuT45VXoI-3HKCOtMuCieGeTJVnN_NT2ZWYzBJuzUu-6yy1MIeXhr1XA$
> >
> ___

Re: [Ifeffit] IFEFFIT file saving issue

[Matt Newville]

Hi Shinhyo,

Again, I would ask to check that the folder you are having trouble saving
to has any non-ASCII characters. For sure, ifeffit and demeter are not
going to be able to handle folder or file names with non-ASCII characters.

Larch is slightly better at this - it can work with files with names in
non-ASCII text encodings.  To be clear, the situation with Larch is still
not ideal, especially on Windows, because
   a) the base installation folder can contain only ASCII characters, and
cannot contain any spaces (apparently this is some problem
   with other libraries or possibly some other variation on point b).
   b) the concept of "localization" on Windows machines is sort of a mess
and many libraries (at least, from Python) don't handle this very well.
For Larch, we recently had to explicitly set locale to be "simple C /
ASCII".  That sort (or should!?) mean that you can read/write files and
folders with non-ASCII characters, though I'm not certain that will work
for all character encoding sets.  It's possible this will get better with
time, but it's not something that we can solve.

For ifeffit / demeter there is simply no hope for non-ASCII text to ever be
handled.


On Tue, Sep 7, 2021 at 7:45 PM Bang, Shinhyo  wrote:

> Dear Matthew,
>
> I tried to save the project onto a usb, and it WORKed! Thank you so much
> for your help.
>
> Best,
> Shinhyo
> --
> *보낸 사람:* Matthew Marcus  대신 Ifeffit <
> ifeffit-boun...@millenia.cars.aps.anl.gov>
> *보낸 날짜:* 2021년 9월 7일 화요일 오후 4:11
> *받는 사람:* ifeffit@millenia.cars.aps.anl.gov <
> ifeffit@millenia.cars.aps.anl.gov>
> *제목:* Re: [Ifeffit] IFEFFIT file saving issue
>
> There are other characters that Windoze doesn't like in filenames:
> |\/*":<>?
> mam
>
> On 9/7/2021 3:58 PM, Matt Newville wrote:
> > Hi Shinhyo, Liane,
> >
> > On Tue, Sep 7, 2021 at 5:39 PM Bang, Shinhyo  > <mailto:shinhyo.b...@wsu.edu >> wrote:
> >
> > Thank you for the response.
> > The OS is Windows 10.
> > In addition to the symptom that was described aforehand, Athena
> > freezes when I try to save the file.
> >
> >
> > Is it possible that the folder or file you are saving to has a space or
> > other non-ASCII character in it?  I believe that non-ASCII characters
> > are known to cause problems.
> > Can you check whether you can save a file anywhere (maybe even the
> > top-level "C:\" folder)?
> >
> > --Matt
> >
> > ___
> > Ifeffit mailing list
> > Ifeffit@millenia.cars.aps.anl.gov
> >
> https://urldefense.com/v3/__http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit__;!!JmPEgBY0HMszNaDT!_9MKQWuqA2MOuT45VXoI-3HKCOtMuCieGeTJVnN_NT2ZWYzBJuzUu-6yy1MIcPr5-UY$
> > Unsubscribe:
> https://urldefense.com/v3/__http://millenia.cars.aps.anl.gov/mailman/options/ifeffit__;!!JmPEgBY0HMszNaDT!_9MKQWuqA2MOuT45VXoI-3HKCOtMuCieGeTJVnN_NT2ZWYzBJuzUu-6yy1MIeXhr1XA$
> >
> ___
> Ifeffit mailing list
> Ifeffit@millenia.cars.aps.anl.gov
>
> https://urldefense.com/v3/__http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit__;!!JmPEgBY0HMszNaDT!_9MKQWuqA2MOuT45VXoI-3HKCOtMuCieGeTJVnN_NT2ZWYzBJuzUu-6yy1MIcPr5-UY$
> Unsubscribe:
> https://urldefense.com/v3/__http://millenia.cars.aps.anl.gov/mailman/options/ifeffit__;!!JmPEgBY0HMszNaDT!_9MKQWuqA2MOuT45VXoI-3HKCOtMuCieGeTJVnN_NT2ZWYzBJuzUu-6yy1MIeXhr1XA$
> ___
> Ifeffit mailing list
> Ifeffit@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] IFEFFIT file saving issue

[Matt Newville]

Hi Shinhyo, Liane,

On Tue, Sep 7, 2021 at 5:39 PM Bang, Shinhyo  wrote:

> Thank you for the response.
> The OS is Windows 10.
> In addition to the symptom that was described aforehand, Athena freezes
> when I try to save the file.
>

Is it possible that the folder or file you are saving to has a space or
other non-ASCII character in it?  I believe that non-ASCII characters are
known to cause problems.
Can you check whether you can save a file anywhere (maybe even the
top-level "C:\" folder)?

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Manuscript comments regarding EXAFS modeling

[Matt Newville]

Hi Peng,

This will echo much of what Matthew Marcus wrote:

For comment 1 on S02, picking a value of 0.85 seems reasonable. I think the
reviewer is asking you to explain how you got that value.  Saying something
like "we chose that value so that the data from a simple metal foil (or
simple metal oxide, etc) gave the expected first shell coordination number"
should be enough.   Typically, S02 is determined once for a given set of
data with the same beamline conditions and *not* varying from sample to
sample.

For comment 2 on correlation, I would emphasize that N and sigma2 are
well-known to be correlated and that this correlation cannot be
eliminated.  The correlation is "managed" as all correlations are managed -
by a statistical analysis of that correlation.  The uncertainties reported
for all fitting variables always take those correlations into account.
That is just a normal part of the analysis.

There is a common misconception that using multiple k-weights "eliminates"
correlations between variables.  It does not.  It is available in
ifeffit/artemis/larch to try to help find more robust solutions.  In my
experience,  simultaneously using k-weights of 1, 2, and 3 does not
actually givr very results compared to using a k-weight of 2 or 3 alone,
though I'm willing to believe that there are cases where it can help find a
solution for a fit with both low-Z and high-Z scatterers.  That is, using
multiple k-weights is a fine thing to do but it does not lower correlations
between N and sigma2 (or E0 and R) by very much.

Cheers,


On Fri, Aug 27, 2021 at 7:41 PM Peng Liu  wrote:

> Dear Ifeffit members,
>
> I received the following two comments.
>
> "
> Comment 1: Authors have fixed the amplitude reduction factor (SO2) to a
> fixed value (0.85). This factor is specific to particular chemical compound
> and sample preparation and quality (mostly homogeneity), measurement method
> (e.g. absorption, fluorescence). Authors can find in literature [e.g.
> Rehr2000] that SO2 for ideal samples (having no other effects) represent
> multielectron effects, which by definition depend on valence and ligands.
> Even more, SO2 is correlated with Debye-Waller factor (σ²) and coordination
> number (CN), so any chosen value will be compensated by CN and σ². As
> coordination numbers are used as quantitative indicators in discussion and
> following conclusions. I would request to clarify the selection criteria
> for SO2 values and advise to revise this approach (i.e. not to fix SO2 as
> the same value for all samples). I do not expect drastic changes in
> obtained CN values, but this should be tested.
>
> Comment 2: As I mentioned previously, coordination number (CN) is
> correlated with Debye-Waller factor (σ²). My question is: how this
> correlation is managed (eliminated)? Most probably (in FEFFIT) this is done
> by using 3 separate values for n (1,2,3), where n is a power in expression
> chi(k)*(k^n).
> "
> I used Artemis for the calculation. 1) Because S02 and CN are
> multiplication relations in the EXAFS equation, as we usually do, we fixed
> S02 to obtain CN for unknown samples. 2) there are outputs regarding the
> correlation between different fitting parameters from Artemis. Is there a
> way to manage or eliminate the correlation as the reviewer mentioned using
> Artemis or Larch?
>
> If you also could give me some suggestions to answer the comments, that
> would also be greatly appreciated.
>
> --
> Best Regards,
>
> Peng Liu
>
> School of Environmental Studies
>
> China University of Geosciences, Wuhan, Hubei Province, PR China
>
> https://scholar.google.com/citations?user=qUtyvokJ=en
> http://grzy.cug.edu.cn/049121/zh_CN/index.htm
> ___
> Ifeffit mailing list
> Ifeffit@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@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Problem Importing CIF files into Larch

[Matt Newville]

Hi Vincent,

Yeah - we are using pymatgen to do the actual CIF parsing, and I think that
part is working fine.  Well, except that it isn't great at identifying
equivalent positions and so tends to give at least 2x more sites than
actually necessary.  In itself, that isn't a huge problem.

The problem that Amol (and, I'm guessing you saw too) was that structures
generated by pymatgen or CrystalMaker, etc won't have some of the fields
currently expected. I started with a restricted set from the AmMin
Database, and was focused on searching through these, so just assumed that
each structure would have a publication -- that is also true for structures
from COD, but won't be true for structures from CrystalMaker or ShelXL.
And right now, the CIF Browser wants to take any CIF you read in and add it
to the database (so you'll have it next time).   But, it should not assume
the CIF file will have all that information

That's all to say that I think this is fixable




On Mon, Aug 16, 2021 at 3:31 PM Vincent Wu  wrote:

> Hello,
>
> I've found that if I have cif files that don't work with Larch, I use
> Pymatgen to read the CIF and output a Pymatgen generated CIF, which would
> then work with Larch. I believe that Pymatgen cleans up cifs in a way, so
> that they become compatible.
>
> Vincent
>
> On Mon, Aug 16, 2021 at 1:22 PM Matt Newville 
> wrote:
>
>> Hi Amol,
>>
>> Sorry for the delay, I was offline most of last week.   Thanks for
>> posting these CIF files.
>> I think these should be usable -- the basic "cif2feffinp()" function
>> works on these to generate a valid Feff.inp,  but the GUI CIF Browser is
>> currently expecting additional fields such as publication information.  I
>> guess those fields should be optional.   I think there is another issue
>> with using multi-site CIF structures that I want to look into.
>> So, I hope to get this fixed soon, but I also want to tackle a few other
>> issues before posting a completely new version.
>>
>> --Matt
>>
>>
>> On Tue, Aug 10, 2021 at 4:12 PM 
>> wrote:
>>
>>> Hi,
>>>
>>> I hope you are doing well. I am writing regarding some issues that I am
>>> having with opening my CIF files in Larch. I have used these same CIF files
>>> in the past in Artemis to run feff calculations. When I open these files in
>>> the Larch open feff tab, it shows a dialog box saying that there is an
>>> error opening the CIF file. This is happening with all my CIF files and I
>>> am not sure why. I am attaching a couple of these CIF files. I would really
>>> appreciate some help on this.
>>>
>>>
>>>
>>> Amol Agarwal
>>>
>>> PhD Student
>>>
>>> Materials Science & Engineering | Northwestern University
>>>
>>>
>>> ___
>>> Ifeffit mailing list
>>> Ifeffit@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@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@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  630-327-7411
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Problem Importing CIF files into Larch

[Matt Newville]

Hi Amol,

Sorry for the delay, I was offline most of last week.   Thanks for posting
these CIF files.
I think these should be usable -- the basic "cif2feffinp()" function works
on these to generate a valid Feff.inp,  but the GUI CIF Browser is
currently expecting additional fields such as publication information.  I
guess those fields should be optional.   I think there is another issue
with using multi-site CIF structures that I want to look into.
So, I hope to get this fixed soon, but I also want to tackle a few other
issues before posting a completely new version.

--Matt


On Tue, Aug 10, 2021 at 4:12 PM  wrote:

> Hi,
>
> I hope you are doing well. I am writing regarding some issues that I am
> having with opening my CIF files in Larch. I have used these same CIF files
> in the past in Artemis to run feff calculations. When I open these files in
> the Larch open feff tab, it shows a dialog box saying that there is an
> error opening the CIF file. This is happening with all my CIF files and I
> am not sure why. I am attaching a couple of these CIF files. I would really
> appreciate some help on this.
>
>
>
> Amol Agarwal
>
> PhD Student
>
> Materials Science & Engineering | Northwestern University
>
>
> ___
> Ifeffit mailing list
> Ifeffit@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@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] Larch 0.9.55

[Matt Newville]

Hi Folks,

Larch 0.9.55 is now available for download.  This comes only two weeks
after the announcement for 0.9.53, but there have been several important
improvements especially for Windows users outside of the US, and based on
bugs found or features requested during the Larch for XAFS Analysis
Workshop at the Virtual XAFS 2021 conference (there was a 0.9.54, but a few
things were fixed since then too!).  If you have installed a recent version
of Larch and are on a machine connected to the internet, you should see a
notice that version 0.9.55 is available, and can use that notice to
automatically install the update.  That will be much faster than installing
from the full installer.

A series of instructional videos made for this workshop on using Larch's
XAS Viewer application for various aspects of XANES and EXAFS analysis are
now publicly available at
https://www.youtube.com/playlist?list=PLgNIl_xwV_vK4V6CmrsEsahNCAsjt8_Be.
Comments, questions, suggestions on these are most welcome, either on
youtube or here.  For folks without access to youtube.com, these videos are
also at  https://millenia.cars.aps.anl.gov/videos/XrayLarch/

The changes here are relatively minor compared to the changes made in
0.9.53 (see
https://millenia.cars.aps.anl.gov/pipermail/ifeffit/2021-July/010251.html).
The most important changes and fixes since 0.9.53 are:

  - Larch's GUI applications should again work without problems on non-US
Windows 10 machines.  There was a serious bug (possibly since Larch 0.9.52)
for using wxPython applications with Python>=3.8 and wxPython>=4.1.0.  I
believe we have a workaround, at least for now.

 - Fixes for turning CIF structures into Feff inputs and running Feff:
-- more external CIF files from Crystallography Open Database and
Materials Project can be converted to Feff.inp.
-- external Feff.inp files can be loaded and run.
-- the name of the folder created for any Feff calculation can be
renamed before running Feff.

 - the plot selection choice in the XAS normalization panel for "one group"
and "selected groups" are no longer reset each time a data set is selected.

 - A reference spectrum can now be set for any XAFS spectrum.  When
aligning or energy-shifting XAFS data, you can now easily select all of the
spectra that share a reference and apply the same energy shift to those
spectra.  You can also easily select a reference group for one XAS spectrum
and copy that to a set of other "selected spectra".   There is not (yet?) a
way to select a reference channel from a file when importing data, so these
must be read separately and assigned.

 - a bug was fixed on the EXAFS / background subtraction panel on "copied
groups" to ensure that processing parameters (kweight, rbkg, etc) are kept
separate.

 - For linear combination fitting, a single energy shift can be varied
during the fit, shifting the unknown data to match the combination of a
(presumably aligned) set of standards.

 - For pre-edge peak fitting and Feff Path fitting, entries in the "fit
history" can have user-specified labels which can be more meaningful than
the default "Fit #1", "Fit #2", etc.

 - testing is now done only with Github Actions, not with the appveyor
service.

I want to thank all the people who took part in the workshop and gave
feedback -- XAS Viewer is a lot better than it was a week ago.  Thanks
to  Monica
Bairagi and Nengchuan Tian for help, and special thanks to Klemen Bucar for
helping track down and solving the Locale issue and working on the testing
tools.  And also thanks to Mauro Rovezzi for continued suggestions and
fixes.

If you have any questions, problems, or suggestions, please let me know.

--Matt
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit