Re: [Ifeffit] Help for EXAFS fitting

2022-09-14 Thread 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

2022-09-14 Thread 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

2022-09-12 Thread 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

2022-09-11 Thread 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

2022-08-29 Thread 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

2022-08-19 Thread 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

2022-08-07 Thread 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

2022-08-06 Thread 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)

2022-07-13 Thread 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

2022-05-31 Thread 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

2022-05-26 Thread 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

2022-05-23 Thread 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

2022-05-14 Thread 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

2022-05-10 Thread 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

2022-04-21 Thread 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

2022-04-04 Thread 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

2022-04-04 Thread 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

2022-04-01 Thread 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

2022-04-01 Thread 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

2022-04-01 Thread 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

2022-04-01 Thread 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

2022-03-24 Thread 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

2022-02-10 Thread 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

2022-02-09 Thread 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

2022-01-24 Thread 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

2022-01-23 Thread 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

2022-01-22 Thread 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

2022-01-16 Thread 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?

2022-01-12 Thread 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

2021-12-15 Thread 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

2021-12-02 Thread 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?

2021-11-15 Thread 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?

2021-11-12 Thread 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

2021-10-20 Thread 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

2021-10-10 Thread 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

2021-10-02 Thread 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

2021-09-07 Thread 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

2021-09-07 Thread 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

2021-09-07 Thread 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

2021-08-29 Thread 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

2021-08-16 Thread 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

2021-08-16 Thread 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

2021-07-18 Thread 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


Re: [Ifeffit] Another Mac OS install question

2021-07-07 Thread Matt Newville
Hi Tom,


On Wed, Jul 7, 2021 at 10:36 AM Jilbert, Tom 
wrote:

> Hi Ifeffit folks,
>
> I am attempting installation via macports on Mac OS Big Sur, and there are
> problems to build demeter. Before I send around a log file, I wanted to
> check if anyone is still maintaining/solving macports issues (Joe Fowler?).
> ie is it worth it to keep trying. From the archive it seems that installing
> a virtual machine is a recommended alternative.
>

That depends on who is doing the recommendation. ;)

A Virtual Windows machine does work for many people.  For myself, I haven't
been able to get Demeter to run on MacOS, even with MacPorts, for at least
a year now (maybe longer).   It's always been a struggle to use this. To be
clear, this is not due to the packaging of Demeter itself but appears to be
that the needed Perl libraries (I've had trouble with "compilers in
general", "Pdl", and "wx") just aren't kept well-tested and up-to-date on
MacPorts. I don't think this is a problem with MacPorts itself either - it
seems to provide many other tools just fine. But something about the
combination of "scientific Perl" with  "perl GUIs using wx" are just not
well-tested / supported enough to make installing Demeter easy and
reliable.  I don't know how that could be solved (and I've looked).

Of course, I will again recommend trying Larch.  It installs and runs on
MacOS (and without requiring MacPorts or X or a Virtual Machine).  The
documentation for using the XAS Viewer GUI is far from extensive, but if
you're familiar with Athena and Artemis, then most analysis steps should
map pretty well onto XAS Viewer.  It also has some features that Athena and
Artemis don't have, especially if Athena and Artemis are using Ifeffit as a
backed.There may be some things that Athena and Artemis can do that XAS
Viewer (or even Larch) cannot do, but at this time I believe those are sort
of down too:

Things I know that Athena/Artemis do that XAS Viewer (and/or Larch) cannot
do:

Automatically import and "tie" data from a reference channel to an
experimental spectrum in the same file.  Worth a discussion.
   GUI interface for a Feff-fit to multiple data sets.  Larch does
support this but only from scripts/Python programs.  That might change, but
not soon.
   Fitting "the background" with the Feff-fit.  That could be
included.  FWIW, Larch/XAS Viewer does use the uncertainty in chi(k) from
background subtraction in the Feff fit.
   Virtual Paths and Paths from Empirical Standards. - not available in
Larch, maybe "consider, if/when requested".
   Have extensive user control of configuration settings.
   Have excellent documentation.  work in progress ;).

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


[Ifeffit] Larch 0.9.53

2021-07-03 Thread Matt Newville
Hi Folks,

Larch 0.9.53 is now available for download and use.  Although the last
announcement here was in April for version 0.9.51, there have been several
improvements especially to the XAS Viewer application since the last
release, mostly in anticipation of upcoming workshops and short courses.

 - There are important fixes for reading Spec/Bliss HDF5 files from ESRF -
thanks to Mauro Rovezzi for this.  You can now import multiple XAS spectra
from Spec/HDF5 files.

 - XAS Viewer now supports doing Feff6l or Feff8l calculations and has a
GUI interface for doing a Feffit fit to a sum of Feff paths.  In the
current GUI frame, this is limited to analyzing one dataset at a time.
This brings up a related feature:

 - A database (sqlite3) of CIF structures from the American Mineralogist
Crystal Structure Database (http://rruff.geo.arizona.edu/AMS/amcsd.php) is
included.  The version of this database in the source code contains about
9000 structures.  If your machine is well-connected to the internet and can
reach https:/millenia.cars.aps.anl.gov, a more complete version (~30 Mb)
with 20,000 structures will be downloaded and used.  To be clear, the 9000
structures in the smaller set are probably sufficient -- what is removed is
some CIFs from publications with many similar structures (T or P
dependence) or structures so large and complex that they will be hard to
make into single Feff files.

 - The CIF files from this DB or other CIF files (well, CIF is notoriously
variable!) can be automatically converted to Feff input files (using python
tools from the Materials Project, modified a bit).  Because many of these
CIF structures contain fractional occupancy, that is handled (probably
poorly, but at least not failing) by randomly selecting atoms based on the
site occupancy.

 - XAS Viewer has a CIF Browser (from the Feff menu) where you can browse
by mineral name, included atoms, etc. From that you can generate a
Feff6l or Feff8l input file, potentially edit that input file, and run Feff
to generate path files. These will be organized in your home folder
(C:\Users\Name\larch\feff for most Windows users, $HOME/.larch/feff for
Linux/MacOS).  There is also a Feff browser to select Feff.dat files
from your previous Feff runs and bring them into the "Feffit" tab in XAS
Viewer to use in the sum of paths fitting of EXAFS spectra.

Of course, all of this Feff and Feff fitting interface should be viewed as
"initial release" and comments, suggestions, and bug reports are welcome.
The notes above are approximately the extent of the documentation, though
some videos of using this will be publicly available in a few weeks.

There are updated binary installers for Windows, MacOSX, and Linux. There
are also updated "GetLarch.sh" and "GetLarch.bat" scripts that also
hopefully fix any earlier problems.  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


Re: [Ifeffit] Cannon start larch on ubuntu 20.04.2 LTS

2021-06-28 Thread Matt Newville
Hi Don,

Hm, very sorry for the trouble.  In fact, I'm hoping to get a new release
out by the end of this week in anticipation of upcoming workshops and
schools, so I'd like to track this down soon.

I don't exactly know what that problem is coming from, but my first
suggestion would be to try to force reinstalling
pymatgen with conda:

~/xraylarch/bin/conda install -c conda-forge pymatgen

I think that ought to work but I'm not sure why the other version failed.
But it might be that taking pymatgen (with several binaries) is better done
from conda anyway.

I'm going to try that on a couple of Linuxes...
--Matt

On Mon, Jun 28, 2021 at 12:42 PM Don Baker, Dr.  wrote:

> Hi Folks,
>
> I think I am missing something obvious and am hoping that you can quickly
> tell me my mistake, so let me begin my story:
>
> I downloaded xraylarch-2021-060Linux-x86_64.sh into downloads on a Asus
> Zenbook using ubuntu 20.04.2 LTS
> I ran the command bash ./xraylarch-2021-060Linux-x86_64.sh
> Larch appears to have been correctly installed, but because I am using a
> gnome desktop no shortcuts appeared on my desktop (as promised) and there
> were no files that   I could identify as shortcuts in my Downloads
> directory (which was set to display hidden files)
> I then moved to the /xraylarch/bin and tried to launch larch using python
> and this is what happened:
>
> python larch
> Traceback (most recent call last):
>   File "larch", line 5, in 
> from larch.apps import run_larch
>   File
> "/home/donb/xraylarch/lib/python3.8/site-packages/larch/__init__.py", line
> 52, in 
> from . import builtins
>   File
> "/home/donb/xraylarch/lib/python3.8/site-packages/larch/builtins.py", line
> 27, in 
> from . import xrd
>   File
> "/home/donb/xraylarch/lib/python3.8/site-packages/larch/xrd/__init__.py",
> line 25, in 
> from .amscifdb import CifStructure, get_amscifdb, get_cif, find_cifs
>   File
> "/home/donb/xraylarch/lib/python3.8/site-packages/larch/xrd/amscifdb.py",
> line 40, in 
> from pymatgen.io.cif import CifParser
>   File
> "/home/donb/xraylarch/lib/python3.8/site-packages/pymatgen/io/cif.py", line
> 25, in 
> from pymatgen.core.composition import Composition
>   File
> "/home/donb/xraylarch/lib/python3.8/site-packages/pymatgen/core/__init__.py",
> line 21, in 
> from .lattice import Lattice  # noqa
>   File
> "/home/donb/xraylarch/lib/python3.8/site-packages/pymatgen/core/lattice.py",
> line 23, in 
> from pymatgen.util.coord import pbc_shortest_vectors
>   File
> "/home/donb/xraylarch/lib/python3.8/site-packages/pymatgen/util/coord.py",
> line 17, in 
> from . import coord_cython as cuc
>   File "pymatgen/util/coord_cython.pyx", line 1, in init
> pymatgen.util.coord_cython
> ValueError: numpy.ndarray size changed, may indicate binary
> incompatibility. Expected 88 from C header, got 80 from PyObject
>
>
> I also tried to use python to start larch_server and xas_viewer and had
> the same results.  I also have the same results if I try to launch larch
> using ./larch
>
> This is the information on the version of Python that I am running:
> Python 3.8.10 (default, Jun  4 2021, 15:09:15)
> [GCC 7.5.0] :: Anaconda, Inc. on linux
> Type "help", "copyright", "credits" or "license" for more information.
>
>
> Any suggestions anyone has to offer will be appreciated.
>
> Wishing you all the best,
>
> Don
>
>
> --
>
> Melting rocks today for a better tomorrow . . .
> Don R. Baker, Professor of Geochemistry, McGill 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
>


-- 
--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] PCA Sixpack results compared to Athena (etc.)

2021-06-10 Thread Matt Newville
Hi Teresa,

I'm sorry that I cannot give you a definitive answer.  I should admit that
when adding PCA methods to Larch and XAS Viewer (which I invite you to try
out), I tried to follow the scikit-learn approach but also to follow the
Athena implementation.  I think I never tried to test against the results
from SixPack.   FWIW, Larch only does (easily) PCA on normalized mu(E) or
its derivative.  I suppose PCA on chi(k) could be added, but I'm a bit sort
of skeptical of this.

In fact, the code at
https://github.com/xraypy/xraylarch/blob/master/larch/math/pca.py (and,
just to be clear, having this both in Python and publicly available is
motivated by having these conversations of "what does it do?") has a few
different methods to train a PCA set: one directly from scikit-learn, one
basically reproducing Demeter's PCA.pm (modulo slight differences in
underlying math libraries, which should be insignificant), one that aims to
use only non-negative components (not really worth in my opinion), and one
that is sort of hand-coded and including the IND statistic.   I don't know
what SixPack does.

I cannot really explain why, but the default "readily exposed in Larch XAS
Viewer" is to use the hand-coded version of `pca_train`.  In fact, they
should be all more or less interchangeable.  I did some tests with these
but that was now several years ago, but it might be worth trying that
again.  If you're up for that, please do try.  If not and would like to
send your project and an outline of what you get, I might be able to look
at this too.

For "target transformation", this is implemented as `pca_fit`: how well can
a data set be explained by the first N components of a training model?

For fit statistics: I have seen "SPOIL" used several places in the EXAFS
literature but am afraid I do not actually know of a definition for this.
If anyone can explain what these are, that would be helpful.   Larch can
calculate the F1 and IND statistics that are more common in the PCA
literature.  XAS Viewer exposes and automatically plots IND - it's a very
useful way to select how many components are significant.

I'm pretty sure that does not answer your actual question, but maybe it
will be helpful.  If you or anyone else has suggestions for additions,
improvements, or other optional methods or statistics for PCA and/or
related methods, please let me know.

--Matt


On Tue, Jun 8, 2021 at 7:43 AM 
wrote:

>
> Dear XAS Community,
>
> I stumbled over the issue that a PCA on 20 EXAFS spectra (k², k =
> 2.0-11.0 Å-1) perfomed in Sixpack does not give the same results
> (Eigenvalues, variance) as in Athena. However, when I use other
> statistical programs (i.e., TIBCO Statistica or SPSS), I get the same
> results as reported in Athena. I tested this with another EXAFS
> dataset of over 30 samples and the problem persited.
>
> An old entry from 2017 in the ifeffit mailing list ("[Ifeffit]
> Calculation of SPOIL value for the reconstruction of standard
> spectra"), told me that as of Sixpack version 1.4 on, a new/different
> PCA algorithm from the scikit-learn Python package is used.


> So I downloaded older versions of Sixpack (i.e. 1.3) and used "Use Old
> PCA"-selection in the "Rotation" menu bar, which actually gave
> different results. However, they are still different from the
> Athena/Statistical program results.
>
> My question is: What is behind this? Is there some sort of
> normalization or axis rotation, that leads to the different values? Is
> there any way to change this so that the results are comparable to
> other programs?
>
> As I need to use the Target Transform option after PCA, which is not
> yet possible in Athena, I am at a loss as to how to deal with these
> different results and where they come from.
>
>
> Thank you very much for your help,
>
> Teresa
>
>
> --
> Teresa Zahoransky
>
> Soil Mineralogy
>
> Gottfried Wilhelm Leibniz Universität Hannover
>
> Institute of Mineralogy
>
> Callinstr. 3, Room 325
>
> D-30167 Hannover, Germany
>
>
>
> Phone: +49 (0)511 762-8058
>
> Email: t.zahoran...@mineralogie.uni-hannover.de
>
> ___
> 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] Analyzing EXAFS data on Artemis

2021-05-27 Thread Matt Newville
Hi Alex,

I agree with everything Carlo and Matthew said.

As you say, Li is very light and so the scattering should be weak compared
to Fe.  It will also die out much more quickly with "k" than the Fe (or Se)
scattering will.  So, if you have enough k-range, simply starting your fit
at higher k than normal (perhaps 4 or 5 Ang^-1) or increasing the k-weight
used in the Fourier transform (perhaps to 3 or 4) would de-emphasize the
Se-Li scattering to a level that it was safe(r) to ignore.

FWIW, I would imagine that trying to fit coordination number or sigma^2 for
Se-Li at percent-level concentrations would not work very well. If you did
indeed get values that were clearly telling you that there was definitely
Se-Li scattering contributing, I would wonder if there was something else
going on (say, from another ligand, some multiple scattering, or some other
phase).

The formula for the Einstein temperature is a scale factor times
"coth(theta/(2t)) / (r_mass * theta)"  where t is the temperature, theta
the Einstein temperature, and r_mass the reduced mass of the atoms in the
path.   See

https://github.com/xraypy/xraylarch/blob/726136d0184d9a006546002722b7573f6c675357/larch/xafs/sigma2_models.py#L19

for details.  This will not include S0^2 -- they are conceptually totally
different.

As Carlo said, the sigma^2 in the EXAFS equation does not distinguish
between static and thermal disorder.  But if you have temperature-dependent
data, modeling the sigma2 values as a static offset + a term that depended
on temperature with an Einstein model would be a fine way to go.

Hope that helps!


On Thu, May 27, 2021 at 9:43 AM Alexandros Deltsidis <
adeltsi...@iesl.forth.gr> wrote:

> Dear mailing list,
>
> I am currently analyzing some EXAFS data. I am studying a Lix(C5H5N)FeSe
> system in a temperature grid that extends from 20 K to 300 K and I have 4
> such datasets which correspond to different amount of doping (x). Right
> now, im focusing on fitting the 1st coordination cell, in Artemis for the
> Se K-edge. My starting model is the simple P4/nmm FeSe. So, in my system
> the 1st coordination cell, in the Se K-edge, corresponds to the Se
> (absorber) - Fe (backscatterer) pair. I have 2 questions:
> 1) I realize now, that I have a certain impurity in the high doping range
> on my system, namely Li2Se. I try to include a scattering path from the
> respective Li2Se crystal model in my fits, since a Se (absorber) - Li
> (backscatterer) pair is present in the R-range of my fit in the Forward
> Fourier Transform. My question here is if this makes sense since Li is
> much smaller scatterer compared to Se. In other words, does it make sense
> to look for physical parameters (Li-Se bond length and DW factor
> respectively) of a signal (Se-Li) that is "tucked" in below the main peak
> coming from the "majority" Se-Fe signal in the FFT?
> 2)Also, I'm attempting to extract an Einstein temperature for each of
> those datasets, by utilizing the "eins(T, thetae)" function implemented in
> Artemis. What is the equation that is parametrized here? Does it include
> the s0^2 offset term that accounts for the overall configuration disorder
> in the system? And if that is the case is there same way to separate it
> from the temperature dependent s^2 term?
>
> Thank you in advance,
> Deltsidis Alexandros
> PS:I am attaching a png. file exported from Artemis that is relative to my
> question 1)
>
> Ph.D candidate,
> Institute of Electronic Structure and Laser (IESL),
> Foundation for Research and Technology - Hellas
> (FORTH)___
> 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] millenia.cars.aps.anl.gov outage starting April 29

2021-04-28 Thread Matt Newville
Hi Folks,

The server millenia.cars.aps.anl.gov that hosts this mailing list and
related services including Webatoms and the binary installers for Larch
will be offline due to a planned power outage at the APS.  We'll gracefully
shut down this server on the afternoon (Chicago time) of April 29th, a bit
more than 24 hours from now.   The estimate for restoring power is May 4th,
but it is possible that the outage will go for another day or so.  During
that time, any messages sent to this list are likely to be lost.

In the meantime, please do consider submitting an abstract for the Virtual
XAFS Conference!

--Matt
PS: if you need to contact me directly by email that will (or should) still
work during the APS power outage.
___
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.51

2021-04-27 Thread Matt Newville
Hi Stefan,


On Tue, Apr 27, 2021 at 12:24 PM Mangold, Stefan (IPS) <
stefan.mang...@kit.edu> wrote:

> Dear all,
>
> tested the latest version on two Macs:
>

Sorry for the trouble.



> M1 on Big Sur
> XAS viewer starts up, but the open dialog doesn’t work, it doesn’t open at
> all
>

Oh, I can definitely believe that there could be problems on M1 chips.  I
don't have access to one of these, at least not yet, so have not done any
testing with that.  I don't know to what extent the underlying python
libraries are well-tested on M1 either.In some ways "XAS Viewer starts
up" is an encouraging sign, but I don't know what might be going wrong from
there.   There isn't much you can do with XAS_Viewer without having read in
some data, so it might be hard to test further.




> old MacPro an 10.12.6
> XAS viewer starts up, but the open dialog starts up, but I get a message,
> the he can’t read in the file or files. These file worked with the older
> version.
>

Oh, can you send the files in question?  There were changes in reading
files that appear to be Spec files, but I think everything else should be
the same.I don't think that OSX 10.12 is old enough to have "known
problems".



> In both cases I started with an anaconda installation and made the update.
>
> Matt, I can sent you more information.
>

Yes, that would be helpful.  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


[Ifeffit] Larch 0.9.51

2021-04-23 Thread Matt Newville
Hi Folks,

Larch 0.9.51 is now available for download and use.   It's been several
months since the last release, and there have been some important
improvements to XAFS data processing and to the XAS Viewer application:

 - Parameters saved in an Athena Project File are now correctly saved and
read into XAS Viewer (thanks Tyler Valentine!)

 - There is now a simple "Apply to all marked groups" feature for pre-edge
peak fitting. That is, you can define a pre-edge peak model with one data
set and then apply it to many others, either inspecting the individual fits
or saving a CSV file with all the parameters and uncertainties for each fit
to each data set.

 - XAS Viewer can now import multiple scans from a Spec file (thanks Mauro
Rovezzi for help with this).  It may seem that Specfiles are "legacy", but
the reader should also be able to handle the ESRF Bliss HDF5 files (as read
in with the silx package, from ESRF), which is their way of efficiently
stacking multiple scans into a single binary file.  While support for this
here should be considered "beta" (or maybe "alpha"!), it is also reasonable
to expect that this or a similar HDF5 format file will become a common way
to collect and store XAFS data.

 - There are binary installers for Windows, MacOSX, and Linux. There are
also now "GetLarch.sh" and "GetLarch.bat" scripts (that are very short)
that can be run to do the download and install, essentially mimicking what
the binary installer does.  This may be useful for folks wanting to install
Larch on multi-user servers or in existing (or "other") Python
environments.
This might also be useful for those who run into permissions issues,
especially on MacOS, where installing a package from an untrusted source is
often blocked by default.  With the installer script, the unprivileged user
is simply running a script that downloads a bunch of files and places them
in the home folder.
These scripts might also be useful for those who run into problems
downloading very large files from millenia.cars.aps.anl.gov, as the
installer scripts will use Anaconda and PyPI resources that are better
distributed throughout the world.

... which brings me to a final note (I'll send out another message next
week):  The APS will have a planned power outage from April 30 to May 4 .
This will take millenia.cars.aps.anl.gov off-line for those 5 +/- 1 days.
That machine hosts the binary installers and also this mailing list.   Mail
sent to this list during that time will likely be lost (email routing
servers can handle destination servers being down for a few hours, but not
days).   So, if you're planning on sending announcements here, either do it
before April 29 or wait until May 5.

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


Re: [Ifeffit] Fourier transform parameters not saved in Larch XAS Viewer

2021-04-18 Thread Matt Newville
Hi Tyler,



On Sun, Apr 18, 2021 at 5:28 PM Tyler Valentine  wrote:

> Hello,
>
> I am using Larch XAS Viewer. I noticed that when I save my work to an
> Athena project file (.prj) and reopen it later, the Fourier transform
> parameters are reset. It seems to be correctly saving other values that I
> set such as the pre-edge and normalization ranges, so I am unsure why it
> does not also save the transform parameters.
>
> Is it possible to have these values saved?
>

Oh, yes you are correct.  This is supposed to work (to save those
parameters)
I'm trying to push out a new release this week, so I'll see if I can fix
that before 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


[Ifeffit] XAFS 2021 Virtual Conference deadlines

2021-04-18 Thread Matt Newville
Hi Folks,

I hope most of you have seen information about the 2021 Virtual XAFS
Conference this summer:https://xafs2021.org/

There will be an in-person conference in the summer of 2022 in Sydney and a
briefer, virtual conference this summer:  11-13 July 2021.

I especially want to draw your attention to the Virtual Poster session for
students and early-career scientists.  The abstract deadline is 1 May, a
little less than two weeks from now: see
https://xafs2021.org/call-for-abstracts.php for details. Please consider
submitting a poster or encouraging your colleagues to do so.

There will also be a Virtual Workshop on Data Analysis with Larch:  I'll be
pre-recording lectures, and then going over some of the finer details of
using XAS Viewer and doing simple XAFS analysis during the workshop.

Hope to see you there,

--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] Artemis fit error - chi-square and R-factors are always equal to 0

2021-03-26 Thread Matt Newville
Hi Ava,

Sorry for the trouble.   It looks to me like the fit actually ran.  Like,
getting non-trivial and non-starting values and uncertainties for 'ss_Cu1',
'dr_Cu1', etc tells me that many parts of the fit and code worked.   I'm
not at all sure why Chi-square and R-factor would report 0.

Do you get a plot of the fit, and if so, does it look reasonable?
Can you send any additional information about how the fit is being defined
- like data file (or is this one of the example Cu data sets?) and feff.dat
file used?

On Fri, Mar 26, 2021 at 6:32 AM Ava Rajh  wrote:

> Hello,
>
> I have recently installed Demeter suite on my LinuxMint 20 machine with
> all required dependencies met. Athena works well and Demeter passed all
> tests during installation. When running Artemis however, there is an
> issue with fits that persists with provided examples any any other
> projects I open (including the ones done by colleagues and just re-run
> on my machine).
>
> After the fit (which completes fine and returns expected fit that looks
> ok when comparing it to experiment), when inspecting the log file,
> chi-square, reduced chi-square and R values are equal to 0 (example log
> file attached bellow). No errors accompany the fit.
>
> I am using Larch installed with anaconda, and Artemis uses Feff6
> executable. I have re-installed Demeter and tried to get it to work with
> Ifeffit but the error persists. I have found an existing git hub thread
> dealing with similar issue
> (https://github.com/bruceravel/demeter/issues/62) but no solution that I
> could discern. Could it be an issue with my perl version (5.30.0)?
>

Maybe.  That issue seemed to start with a problem of not being able to find
and run Feff.
I don't know if that is relevant for you - it sure seems like Feff6 ran for
you - can you verify that?

I'm also not sure if that issue ever got resolved.  I was sure confused
about what was going on there.

For sure, it is much easier for me to support and help folks using Larch.
Can you verify that the example fitting scripts for Larch (see
https://github.com/xraypy/xraylarch/tree/master/examples/feffit ) work for
you?

--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] Not possible to install Larch MacOS X 10.12.6 via anaconda (see report)

2021-03-16 Thread Matt Newville
Hi Stefan,

Oh, that's odd,  WxPython must have been installed for anything to have
worked before.  But maybe it got removed during an Anaconda upgrade (I'm
not sure of that, but maybe...)   I suggest trying   `conda install -c
conda-forge wxpython`

On Tue, Mar 16, 2021 at 1:57 AM Mangold, Stefan (IPS) <
stefan.mang...@kit.edu> wrote:

> Hi Matt,
>
> here is the output. I work directly on this machine and not via remote
> login
>
> bash-3.2$ xas_viewer
> Traceback (most recent call last):
>   File "/Users/myloginname/opt/anaconda3/bin/xas_viewer", line 8, in
> 
> sys.exit(run_xas_viewer())
>   File
> "/Users/myloginname/opt/anaconda3/lib/python3.8/site-packages/larch/apps.py",
> line 146, in run_xas_viewer
> from larch.wxxas import XASViewer
>   File
> "/Users/myloginname/opt/anaconda3/lib/python3.8/site-packages/larch/wxxas/__init__.py",
> line 1, in 
> from .taskpanel  import TaskPanel, FONTSIZE
>   File
> "/Users/myloginname/opt/anaconda3/lib/python3.8/site-packages/larch/wxxas/taskpanel.py",
> line 10, in 
> import wx
> ModuleNotFoundError: No module named ‚wx‘
>
>
>
>
> Am 16.03.2021 um 03:23 schrieb Matt Newville :
>
> Hi Stefan,
>
>
> Sorry, my earlier suggestions were automatically for Windows.  On MacOS,
> it would be pretty similar, but "open a Terminal" and then make sure that
> /Users/USERNAME/xraylarch exists and is in your path.
>
> To launch xas_viewer, you *should* be able to do
>
>  %>  xas_viewer
>
> but you might need (note "pythonw", not "python"!)
>
>  %> pythonw ~/xraylarch/bin/xas_viewer
>
> The rest of the advice is basically the same:  try to do a conda update
> and/or report what error messages you get.
>
> On MacOS, if you get
>
>  This program needs access to the screen. Please run with a Framework
> build of python,
>  and only when you are logged in on the main display of your Mac.
> then you need to make sure you're running with "pythonw", not "python".
>
>
>
> On Mon, Mar 15, 2021 at 5:32 PM Matt Newville 
> wrote:
>
>> Hi Stefan,
>>
>> Sorry for the trouble.  It's always a little tricky to diagnose a problem
>> of "it doesn't work", but here are a couple of things to try:
>>
>> If you can open the Anaconda Prompt (from Start Menu it may be under
>> "Anaconda3 (64-bit) and then "Anaconda Prompt (xraylarch)") where you ran
>> 'larch -m" from, try running
>>
>> C:>   xas_viewer
>>
>> That is supposed to run, but I suspect that it might print out some error
>> messages.  If I had to guess, some package is not correctly installed.
>>
>> Second, it might be helpful just to run (from the same prompt):
>>
>> C:> conda update --all
>>
>>
>> and see if that installs some updates or spins forever.  If it finishes,
>> then try running "xas_viewer" again.
>>
>> Third, you could just try reinstalling from scratch.  That might be
>> "easiest", but if you have the patience to try the other approaches above
>> it would help identify what the problem is.
>>
>> --Matt
>>
>>
>> On Mon, Mar 15, 2021 at 7:59 AM Mangold, Stefan (IPS) <
>> stefan.mang...@kit.edu> wrote:
>>
>>> Thanks Matt,
>>>
>>> installation worked. But still have the problem, that I can’t start XAS
>>> Viewer. I executed also larch -m (no error message).
>>>
>>> regards
>>>
>>> Stefan
>>>
>>> Am 13.03.2021 um 16:35 schrieb Matt Newville >> >:
>>>
>>> Hi Stefan, Morgane, All,
>>>
>>> Yeah, sorry for the trouble with this.   I should admit I've had
>>> increasing struggles over the past year or two with maintaining packages
>>> for Anaconda Python, running into many painful claims of incompatible
>>> packages.Most of the "core scientific python packages" are
>>> well-maintained by Anaconda.com <http://anaconda.com/> -- it's hard to
>>> complain about this free distribution and all of the work that goes into
>>> it.   But the "non-Anaconda-provided" packages make Larch more complicated,
>>> and the xraylarch "conda" package is out-of-date.
>>>
>>> The semi-good news on this front is that almost everything, including
>>> Larch, is actually available from the PyPI packaging system and can be
>>> installed with "pip".  Anaconda and its "conda" package-manager will
>>>

Re: [Ifeffit] Not possible to install Larch MacOS X 10.12.6 via anaconda (see report)

2021-03-15 Thread Matt Newville
Hi Stefan,


Sorry, my earlier suggestions were automatically for Windows.  On MacOS, it
would be pretty similar, but "open a Terminal" and then make sure that
/Users/USERNAME/xraylarch exists and is in your path.

To launch xas_viewer, you *should* be able to do

 %>  xas_viewer

but you might need (note "pythonw", not "python"!)

 %> pythonw ~/xraylarch/bin/xas_viewer

The rest of the advice is basically the same:  try to do a conda update
and/or report what error messages you get.

On MacOS, if you get

 This program needs access to the screen. Please run with a Framework
build of python,
 and only when you are logged in on the main display of your Mac.
then you need to make sure you're running with "pythonw", not "python".



On Mon, Mar 15, 2021 at 5:32 PM Matt Newville 
wrote:

> Hi Stefan,
>
> Sorry for the trouble.  It's always a little tricky to diagnose a problem
> of "it doesn't work", but here are a couple of things to try:
>
> If you can open the Anaconda Prompt (from Start Menu it may be under
> "Anaconda3 (64-bit) and then "Anaconda Prompt (xraylarch)") where you ran
> 'larch -m" from, try running
>
> C:>   xas_viewer
>
> That is supposed to run, but I suspect that it might print out some error
> messages.  If I had to guess, some package is not correctly installed.
>
> Second, it might be helpful just to run (from the same prompt):
>
> C:> conda update --all
>
>
> and see if that installs some updates or spins forever.  If it finishes,
> then try running "xas_viewer" again.
>
> Third, you could just try reinstalling from scratch.  That might be
> "easiest", but if you have the patience to try the other approaches above
> it would help identify what the problem is.
>
> --Matt
>
>
> On Mon, Mar 15, 2021 at 7:59 AM Mangold, Stefan (IPS) <
> stefan.mang...@kit.edu> wrote:
>
>> Thanks Matt,
>>
>> installation worked. But still have the problem, that I can’t start XAS
>> Viewer. I executed also larch -m (no error message).
>>
>> regards
>>
>> Stefan
>>
>> Am 13.03.2021 um 16:35 schrieb Matt Newville > >:
>>
>> Hi Stefan, Morgane, All,
>>
>> Yeah, sorry for the trouble with this.   I should admit I've had
>> increasing struggles over the past year or two with maintaining packages
>> for Anaconda Python, running into many painful claims of incompatible
>> packages.Most of the "core scientific python packages" are
>> well-maintained by Anaconda.com -- it's hard to complain about this free
>> distribution and all of the work that goes into it.   But the
>> "non-Anaconda-provided" packages make Larch more complicated, and the
>> xraylarch "conda" package is out-of-date.
>>
>> The semi-good news on this front is that almost everything, including
>> Larch, is actually available from the PyPI packaging system and can be
>> installed with "pip".  Anaconda and its "conda" package-manager will
>> regularly say to not mix "conda" and "pip", but this mostly applies to
>> cases where C code is going to be compiled on installation, which we don't
>> do.
>>
>> What I'm now doing for building the binary distributions, and what I
>> recommend for updating is:
>>1. install a basic Anaconda distribution - this can be from the Larch
>> binary installers.
>>2. install or update the Larch code with  "pip install --upgrade
>> xraylarch".
>>
>> I should probably take another look at adding xraylarch to the
>> large-and-diverse "conda_forge" channel for the "conda" system.
>>
>> Hope that helps, and suggestions on how to handle this better would be
>> most welcome,
>>
>> --Matt
>>
>>
>> On Fri, Mar 12, 2021 at 10:07 AM Morgane Desmau 
>> wrote:
>>
>>> Hello,
>>>
>>> I already had this issue and it was related to the python version (6/7
>>> months ago with python 3.8, and then it worked with Python 3.7, but I was
>>> thinking it was fixed since).
>>>
>>> Best,
>>> Morgane Desmau
>>>
>>> Le ven. 12 mars 2021 à 16:55, Mangold, Stefan (IPS) <
>>> stefan.mang...@kit.edu> a écrit :
>>>
>>>> Dear all,
>>>>
>>>> I tried to reinstall; before I updated and couldn’t open larch anymore
>>>>
>>>>
>>>> conda install -yc GSECARS xraylarch
>>>> Collecting package metadata (current_repodata.json): done
>&

Re: [Ifeffit] Not possible to install Larch MacOS X 10.12.6 via anaconda (see report)

2021-03-15 Thread Matt Newville
Hi Stefan,

Sorry for the trouble.  It's always a little tricky to diagnose a problem
of "it doesn't work", but here are a couple of things to try:

If you can open the Anaconda Prompt (from Start Menu it may be under
"Anaconda3 (64-bit) and then "Anaconda Prompt (xraylarch)") where you ran
'larch -m" from, try running

C:>   xas_viewer

That is supposed to run, but I suspect that it might print out some error
messages.  If I had to guess, some package is not correctly installed.

Second, it might be helpful just to run (from the same prompt):

C:> conda update --all


and see if that installs some updates or spins forever.  If it finishes,
then try running "xas_viewer" again.

Third, you could just try reinstalling from scratch.  That might be
"easiest", but if you have the patience to try the other approaches above
it would help identify what the problem is.

--Matt


On Mon, Mar 15, 2021 at 7:59 AM Mangold, Stefan (IPS) <
stefan.mang...@kit.edu> wrote:

> Thanks Matt,
>
> installation worked. But still have the problem, that I can’t start XAS
> Viewer. I executed also larch -m (no error message).
>
> regards
>
> Stefan
>
> Am 13.03.2021 um 16:35 schrieb Matt Newville :
>
> Hi Stefan, Morgane, All,
>
> Yeah, sorry for the trouble with this.   I should admit I've had
> increasing struggles over the past year or two with maintaining packages
> for Anaconda Python, running into many painful claims of incompatible
> packages.Most of the "core scientific python packages" are
> well-maintained by Anaconda.com -- it's hard to complain about this free
> distribution and all of the work that goes into it.   But the
> "non-Anaconda-provided" packages make Larch more complicated, and the
> xraylarch "conda" package is out-of-date.
>
> The semi-good news on this front is that almost everything, including
> Larch, is actually available from the PyPI packaging system and can be
> installed with "pip".  Anaconda and its "conda" package-manager will
> regularly say to not mix "conda" and "pip", but this mostly applies to
> cases where C code is going to be compiled on installation, which we don't
> do.
>
> What I'm now doing for building the binary distributions, and what I
> recommend for updating is:
>1. install a basic Anaconda distribution - this can be from the Larch
> binary installers.
>2. install or update the Larch code with  "pip install --upgrade
> xraylarch".
>
> I should probably take another look at adding xraylarch to the
> large-and-diverse "conda_forge" channel for the "conda" system.
>
> Hope that helps, and suggestions on how to handle this better would be
> most welcome,
>
> --Matt
>
>
> On Fri, Mar 12, 2021 at 10:07 AM Morgane Desmau 
> wrote:
>
>> Hello,
>>
>> I already had this issue and it was related to the python version (6/7
>> months ago with python 3.8, and then it worked with Python 3.7, but I was
>> thinking it was fixed since).
>>
>> Best,
>> Morgane Desmau
>>
>> Le ven. 12 mars 2021 à 16:55, Mangold, Stefan (IPS) <
>> stefan.mang...@kit.edu> a écrit :
>>
>>> Dear all,
>>>
>>> I tried to reinstall; before I updated and couldn’t open larch anymore
>>>
>>>
>>> conda install -yc GSECARS xraylarch
>>> Collecting package metadata (current_repodata.json): done
>>> Solving environment: failed with initial frozen solve. Retrying with
>>> flexible solve.
>>> Solving environment: failed with repodata from current_repodata.json,
>>> will retry with next repodata source.
>>> Collecting package metadata (repodata.json): done
>>> Solving environment: failed with initial frozen solve. Retrying with
>>> flexible solve.
>>> Solving environment: /
>>> Found conflicts! Looking for incompatible packages.
>>> This can take several minutes.  Press CTRL-C to abort.
>>> failed
>>>
>>>
>>>
>>>
>>> UnsatisfiableError: The following specifications were found to be
>>> incompatible with each other:
>>>
>>>
>>> ___
>>> 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
>> ht

Re: [Ifeffit] Not possible to install Larch MacOS X 10.12.6 via anaconda (see report)

2021-03-13 Thread Matt Newville
Hi Stefan, Morgane, All,

Yeah, sorry for the trouble with this.   I should admit I've had increasing
struggles over the past year or two with maintaining packages for Anaconda
Python, running into many painful claims of incompatible packages.Most
of the "core scientific python packages" are well-maintained by
Anaconda.com -- it's hard to complain about this free distribution and all
of the work that goes into it.   But the "non-Anaconda-provided" packages
make Larch more complicated, and the xraylarch "conda" package is
out-of-date.

The semi-good news on this front is that almost everything, including
Larch, is actually available from the PyPI packaging system and can be
installed with "pip".  Anaconda and its "conda" package-manager will
regularly say to not mix "conda" and "pip", but this mostly applies to
cases where C code is going to be compiled on installation, which we don't
do.

What I'm now doing for building the binary distributions, and what I
recommend for updating is:
   1. install a basic Anaconda distribution - this can be from the Larch
binary installers.
   2. install or update the Larch code with  "pip install --upgrade
xraylarch".

I should probably take another look at adding xraylarch to the
large-and-diverse "conda_forge" channel for the "conda" system.

Hope that helps, and suggestions on how to handle this better would be most
welcome,

--Matt


On Fri, Mar 12, 2021 at 10:07 AM Morgane Desmau 
wrote:

> Hello,
>
> I already had this issue and it was related to the python version (6/7
> months ago with python 3.8, and then it worked with Python 3.7, but I was
> thinking it was fixed since).
>
> Best,
> Morgane Desmau
>
> Le ven. 12 mars 2021 à 16:55, Mangold, Stefan (IPS) <
> stefan.mang...@kit.edu> a écrit :
>
>> Dear all,
>>
>> I tried to reinstall; before I updated and couldn’t open larch anymore
>>
>>
>> conda install -yc GSECARS xraylarch
>> Collecting package metadata (current_repodata.json): done
>> Solving environment: failed with initial frozen solve. Retrying with
>> flexible solve.
>> Solving environment: failed with repodata from current_repodata.json,
>> will retry with next repodata source.
>> Collecting package metadata (repodata.json): done
>> Solving environment: failed with initial frozen solve. Retrying with
>> flexible solve.
>> Solving environment: /
>> Found conflicts! Looking for incompatible packages.
>> This can take several minutes.  Press CTRL-C to abort.
>> failed
>>
>>
>>
>> UnsatisfiableError: The following specifications were found to be
>> incompatible with each other:
>>
>>
>> ___
>> 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] Larch Energy calibration

2021-03-09 Thread Matt Newville
Hi Valerie,

Sorry for the delay.

On Fri, Mar 5, 2021 at 10:06 AM Schoepfer, Valerie <
valerie.schoep...@usask.ca> wrote:

> Hi Matt,
>
> The backstory is that I'm trying to find which standards will define my
> samples, so I am pulling standards from different beamlines and years to
> get a basic linear combination fit, to run new standards myself when I have
> more beamtime.
>
> I'm able to do it in Athena- where you more or less:
> 1. Assign E0 to the first peak in the first derivative of your standard
> reference foil.
> 2. Calibrate one standard reference foil to the theoretical edge energy.
> 3. Ensure E0 is right/adjust E0 for all samples and sample foils.
> 4. Align reference foils to the standard reference foil, because the foil
> will pull the sample with it.


> But in Larch, maybe I'm unsure about the groups function?  I'm not
> convinced the reference foils 'follow' the sample spectra.
> If the reference and samples aren't tied together, how do you align
> samples when your energies are off because of different beamlines or years
> or people not as careful to calibrate the beamline energy?
> My first thought was using the first derivative peak of your sample, but
> if your edge energy shifts because of oxidation state changes, what do you
> use then?
>

It is true that Larch's XAS Viewer does not really expose the concept of
each spectrum having its own reference channel.  I guess that reflects my
own bias that if each spectrum in a set of measurements really needs its
own reference, there is a serious problem with the measurements - like, the
monochromator needs fixing.  (Aside: if the energy drifts significantly
from scan to scan, how do we know how to align the energies?).  It probably
also reflects my reality that most of the work I do is in fluorescence and
on samples that will have no transmission, and are done on a beamline where
an "elf-like" scatter measurement is not practical.

But, for sure, if you measure sets of data at different beamlines or even
at the same beamline but weeks apart, you may need to apply energy shifts
to get those *sets* of data to be aligned.   Admittedly, if you're pulling
in standard spectra from many sources, this can be a little tedious but (in
principle) only needs to be done once.

In Larch's XAS Viewer, you can go to the Data->Recalibrate Energy menu to
bring up a window for aligning one spectrum to another.  So, if you have
two sets of data and have measured the same calibrant (say, Mo foil) at
both, you can read in the foil spectra and align them:  Select the data
group for the spectrum from "new foil" and auto-align that to the spectrum
of the "good foil".With that energy shift (this dialog only does a
constant energy shift, not an angular offset or lattice-spacing offset)
determined, you can apply that shift to any number of Selected Groups, say
all the spectrum measured along with "new foil" spectrum.

Does that seem workable for what you're trying to do?

I guess that if you have a reference channel measured for each spectrum,
you could also read those reference spectra in and see how much their edge
positions vary, assess the variation in those positions, identify outliers,
and so forth.

--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 energy calibration

2021-03-03 Thread Matt Newville
Hi Valerie,

On Tue, Mar 2, 2021 at 10:48 AM Schoepfer, Valerie <
valerie.schoep...@usask.ca> wrote:

> Hi,
>
>
>
> I am using Larch XAS Viewer for the first time to analyze some Mo XANES
> data. It is fairly straightforward, however I am running into problems with
> energy calibration, which leads to problems with Linear Combination
> Fitting.
>
>
>
> Right now, which is likely wrong, I’m calibrating the energy of a standard
> to the theoretical edge, then auto-aligning the samples to the standard.
> But how do reference foils fit in here? Reference foils don’t seem to be
> tied to the sample like they are in Athena. Should I be manually aligning?
>
>
>
> Is there a general guidance or work flow?
>

It's possible that I do not fully understand the question or that this
answer will veer a bit off the topic of your question.

For sure, energies need to be aligned properly for any multi-spectra
comparison or linear method to work well. But it should be that you will
have groups of spectra that all share a consistent energy calibration, say
from the same beamline/beamtime.

If you do have a reference channel for every measurement, you can compare
those reference channels.  Ideally, these will not vary for every
measurement - that would indicate a serious problem.   So, I think you
should be able to group spectra together as uniformly calibrated (hopefully
all data from a day or more of beamtime at a particular beamline) and then
make sure that the different groups of spectra.  Does that seem reasonable?

I have to admit that at my beamline I don't often have the luxury or need
to run a reference foil for every scan, so we calibrate consistently ahead
of time.  I'm sure that leads to a bias in the software.   I guess I forgot
that Athena had the ability to read and tie a second spectrum as a
"reference" and use that to auto-apply calibration.

Is it generally necessary to calibrate many spectra individually, or do
people find that doing them in a few large groups is sufficient?

--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: AttributeError

2021-01-13 Thread Matt Newville
Hi Rachita,

On Wed, Jan 13, 2021 at 2:00 PM Rachita Rana  wrote:

> Hi Everyone,
>
> I am using Larch for reading and fitting EXAFS data and I get the autobk
> and Fourier transforms working. But when I try to generate the fefffpaths
> and fit the data I get an error from the feffit function. I am using the
> developer version of Larch on MC OS Catalina. Below is the error and the
> sample script-
>
> *runfile('/Users/rachita/Box/Larch/Feff_Try2/001.py',
> wdir='/Users/rachita/Box/Larch/Feff_Try2')*
> *Traceback (most recent call last):*
>
> *  File "/Users/rachita/Box/Larch/Feff_Try2/001.py", line 27, in *
> *fit   = feffit(params, dset)*
>
> *  File
> "/Users/rachita/opt/anaconda3/lib/python3.8/site-packages/xraylarch-0.9.50-py3.8.egg/larch/xafs/feffit.py",
> line 534, in feffit*
> *ds.prepare_fit(params=params)*
>
> *  File
> "/Users/rachita/opt/anaconda3/lib/python3.8/site-packages/xraylarch-0.9.50-py3.8.egg/larch/xafs/feffit.py",
> line 265, in prepare_fit*
> *ikmax = int(1.01 + max(self.data.k)/trans.kstep)*
>
> *AttributeError: 'AthenaGroup' object has no attribute ‘k’ #tried this
> with xdi format data and got the same error*
>


I think this is because your script actually did not do the background
subtraction.  The "read_xdi()" command reads in the raw data, which
probably contains "energy" and "mu" arrays, but not "k" and "chi" arrays.
 You said you got autobk and ffts working, you probably want to just add a

   autobk(data, rbkg=1.0)

command  (maybe with other options).  That will add "k" and "chi" arrays to
the "data" group, which feffit() is expecting.

I guess the error message could be clearer there





> *Below is the script -*
>
> #!/usr/bin/env python3
> # -*- coding: utf-8 -*-
> from larch.fitting import param_group, Parameter
> from larch.io import read_xdi
> from larch.xafs import feffpath, feffit_dataset, feffit_transform, feffit,
> feffit_report
>
> data = read_xdi('cu_metal_rt.xdi’)   *#I tried importing Athena project
> file too *
>
> path1 = feffpath('feff0001.dat', s02='amplitude', e0='del_e0',
>  sigma2='sigma2', deltar='del_r')
>
> trans = feffit_transform(kmin=3, kmax=16, kw=(2,1,3),
>  dk=1, window='hanning', rmin=1.7, rmax=3.1)
>
> params = param_group(amplitude= Parameter(1, vary=True),
>  del_e0   = Parameter(1e-7,  vary=True),
>  del_r= Parameter(1e-7,  vary=True),
>  sigma2   = Parameter(0.003, vary=True))
>
> dset  = feffit_dataset(data=data, pathlist=[path1], transform=trans)
> fit   = feffit(params, dset)
>
> print(feffit_report(fit))
>
> By printing path groups and transform fit, I confirmed that the data is
> read correctly.
>
> Please let me know if there are ways to fix this or if there is an error
> in my script.
>
> Thank You!
>
> Rachita
> ___
> 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] How do I create a histogram based on R-space values

2020-12-10 Thread Matt Newville
Deepak,

On Wed, Dec 9, 2020 at 9:27 PM Deepak Varanasi  wrote:

> Good evening
>
> May I also know how to calculate the necessary ingredients in building a
> histogram such as R and N?
>

The analysis of EXAFS to extract structural parameters is slightly
complex.  There is quite a bit of literature on how to do this. I may
suggest looking at the books listed at
https://xafs.xrayabsorption.org/tutorials.html, especially the two by Grant
Bunker and Scott Calvin.

I suppose R is just the R-space stuff so how do I calculate N?
>

Hm, well actually it kind of isn't.

> Is it simply the number of peaks in my R-space graph or something else
> entirely?
>

No, it is not simply the number of peaks in the plot of |chi(R)|.  The
positions and intensities of those peaks do depend on the distribution of
distances, g(R), but also depend in non-trivial ways on scattering factors
of the photo-electron created in the absorption process.

> I need to be able to construct the histogram to finish my thesis and
> graduate but I am still stuck on it. Hence, may I request your guidance on
> this please?
>

EXAFS data is not simply "converted" to a histogram of distances, g(R).
EXAFS does depend on g(R) and an analysis of the EXAFS signals can provide
information about the local structure.

I hope that helps, but it appears you are confusing |chi(R)| (the magnitude
of the Fourier transform of the EXAFS oscillations) with g(R).   They are
related, but that relationship is not simple enough to allow a simple
conversion from |chi(R)| to g(R).

--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 create a histogram based on R-space values

2020-12-09 Thread Matt Newville
Deepak,

The data files you sent appear to be plots of XAFS |chi(R)|, including
offsets for the plotting.  That is certainly a reasonable visualization to
make for EXAFS data and Demeter can make those easily.

But |chi(R)| is not a histogram of the number of atoms as a function of
distance.  That is sort of all of "EXAFS analysis" and unfortunately there
is not a simple transform that converts |chi(R)| into g(R).   I recommend
looking at some of the on-line resources and books and review articles on
EXAFS.

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] Athena error on Linux mint

2020-10-26 Thread Matt Newville
Hi Kyle,

I've seen the same message with Perl 5.30 on Fedora 32 as well.  I believe
you need to do:
perl -I. Build.PL

That is, explicitly tell Perl to look in the current folder for files to
import.

Good luck with the build though -- I haven't built it successfully on
Fedora32 yet, but I have not tried in a few months.   You may also find
some of the hints by Vasily Lebedev at
https://github.com/bruceravel/demeter/issues/62 and links therein to
Pastebin configs and hacks to get Demeter to build.



On Mon, Oct 26, 2020 at 5:55 PM Kyle Kluherz  wrote:

> I recently successfully installed the Demeter suite on my Linux Mint 19
> machine. Last week, I updated to Linux Mint 20, and now I get the following
> error when trying to run athena from the command line:
>
> Can't locate Demeter/Here.pm in @INC (you may need to install the 
> Demeter::Here module) (@INC contains: /etc/perl 
> /usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0 
> /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 
> /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 
> /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at 
> /usr/local/bin/dathena line 7.
> BEGIN failed--compilation aborted at /usr/local/bin/dathena line 7.
>
> I was wondering if there was a relatively easy way to fix this, or if the
> best recourse is to simply reinstall Demeter? It took some fiddling to
> install initially, so I don't want to reinstall it unless that's the
> easiest way to fix the issue.
>
> Also, the mailing list link on the Demeter home page (
> http://cars9.uchicago.edu/mailman/listinfo/ifeffit/) times out.
> Fortunately I was able to get a working link (
> https://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit) from a friend.
>
> Sincerely,
>
> Kyle Kluherz
>
> --
> Kyle (Tk) Kluherz
> Graduate Student
> Gamelin & De Yoreo groups
> Department of Chemistry, UW
> Materials Science Division, PNNL
>
> ___
> 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-252-0431
___
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 Question

2020-10-07 Thread Matt Newville
Hi Nicholas,

On Wed, Oct 7, 2020 at 10:02 PM Nicholas Weingartz <
nicholasweingartz2...@u.northwestern.edu> wrote:

> Hello List,
>
> I'm having a strange problem with my EXAFS fits in Artemis in which they
> seem to fly off at higher k.  I was having trouble with background fitting
> a particularly messy data set and I wanted more control over this so I used
> the program PySpline to fit the background after I did the rest of the
> preprocessing in Athena.  I then imported the data into Athena and loaded
> the project into Artemis.  Interestingly, when I only include a single path
> in the fit and plot both the single path and the overall fit, the single
> path does not fly off but the overall fit does.  I have attached an image
> of the issue.  When I use the spline fitting built into athena, I do not
> encounter this issue.  Has anyone ever experienced this issue before?
>
>
Sorry, but I'm not sure I understand what the issue is from that plot.  You
said "the single path does not fly off but the overall fit does" but I sort
of don't see that in the image you show.   Is something flying off there?

The k-range you show appears to be pretty limited to me, roughly k=3 to 9
Ang^-1.   For a single path, I can certainly believe that actually is the
"best fit" even if it not "very good".  But it's hard to say from only one
view of the fit.

If you suspect (or well, "made") the splines be different, I might suggest
looking at the mu0(E) arrays themselves, or perhaps plotting the k^2*chi(k)
for the two background subtraction.


--Matt

Thanks for your help!
>
> Nicholas Weingartz
>
> Ph.D Student
> Department of Chemistry
> Northwestern University
>
> [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
>
___
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] Core-hole Lifetimes in Hephaestus 0.9.26

2020-09-28 Thread Matt Newville
Hi Daniel,



On Mon, Sep 28, 2020 at 2:15 PM Daniel Przyrembel <
daniel.przyrem...@fu-berlin.de> wrote:

> Hi Matt,
>
> Well, independent of what Krause et al. have done, the correct uncertainty
> relation between core-hole widths as FWHM (full width at half maximum) and
> the lifetime is
>
> lifetime = h_bar / FWHM
>
> from the corresponding half-width (HWHM) expression
>
> HWHM x lifetime >= h_bar / 2
>
> Again, I just stumbled upon this when using Hephaestus, and the lifetimes
> were all oddly "long".
> The above relations are often garbled up due a HWHM-FWHM mix-up (the HWHM
> being the "spread" of the Cauchy/Lorentz/Breit-Wigner distribution towards
> higher and lower energy around the center etc.) as well, giving factor of
> two errors...
>
>
Yeah, I think most of us in the X-ray spectroscopy community think in eV
and not in fs.  ;) But it would obviously be better to report those
lifetimes better too.

I don't really have a strong feeling on whether reporting FWHM or HWHM (or
sigma, for non-Lorentzians), but consistency is good.  For sure, the values
from Krause et al are well-used in the X-ray spectroscopy community.  But,
well should that 'lifetime' be a 1/e value?

--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] Core-hole Lifetimes in Hephaestus 0.9.26

2020-09-28 Thread Matt Newville
Hi,

Ah, Krause et al *do* use hbar, not h, so yeah With gamma = 0.2 eV, and h
~= 4.13567e-15 eVs (hbar ~ 6.582e-16 eVs), then lifetime is ~3 fs.

That is probably the mistake that hephaestus is making too.  FWIW, we are
not currently, but could be reporting core-level widths and lifetimes at
https://xraydb.xrayabsorption.org/


On Mon, Sep 28, 2020 at 1:37 PM Matt Newville 
wrote:

> I believe it is using (or intends to use)
>
> lifetime = hbar /gamma
>
> which is what Krause et al give.  With gamma = 0.2 eV, and hbar ~=
> 4.13567e-15 eVs, then lifetime is ~20fs.
> Maybe I'm missing something more subtle?  FWIW, these reported numbers for
> gamma in eV are described by Krause et al as "FWHM".
>
> --Matt
>
>
> On Mon, Sep 28, 2020 at 1:13 PM Daniel Przyrembel <
> daniel.przyrem...@fu-berlin.de> wrote:
>
>> Hi Matt,
>>
>> Thanks for the quick reply!
>> However, I seem to not have made clear my concern...
>>
>> The widths in energy (eV) are fine.
>>
>> However, in "Hephaestus", the "souped-up periodic table for the X-ray
>> absorption spectroscopist", these level widths in energy (eV) are also
>> given as equivalent lifetimes (in fs), however incorrectly: A level width
>> of ~0.2 eV in fact corresponds to a lifetime of ca. 3 fs, not ~30 fs as
>> given there.
>>
>> Those lifetimes shown in Hephaestus all seem to be off by a general factor
>> of 10. I guess that is just the energy width/lifetime conversion gone
>> slightly wrong...
>> I imagine I'm not the only one using Hephaestus as a convenient tool to
>> look stuff up quickly, so I thought it might be useful to point out this
>> flaw.
>>
>> Just to make sure, I have again imported the xraydb: That has not changed
>> Hephaestus' behavior in terms of the lifetime info (I'm using the latest
>> 64-bit version on Windows).
>>
>>
>> > Hi Daniel,
>> >
>> > Thanks - that does seem wrong.  FWIW, Larch uses XrayDB which uses
>> > corehole
>> > widths from Krause and Oliver for Z>10 and Keski-Rahkoken nand Krause
>> for
>> > Z<10.
>> > For the F K edge, this give 0.2089 eV.  For this or other core-hole
>> > widths,
>> > and assuming you have Python installed, try:
>> >
>> >   ~> pip install xraydb
>> >   ~> python
>> >   >>> import xraydb
>> >   >>> xraydb.core_width('F', 'K')
>> >   0.2089
>> >
>> > Or install Larch and use
>> >
>> >~> larch
>> >larch> core_width('F', 'K')
>> >0.2089
>> >
>> >
>> >
>> > On Mon, Sep 28, 2020 at 12:08 PM Daniel Przyrembel <
>> > daniel.przyrem...@fu-berlin.de> wrote:
>> >
>> >> To Whom it may concern,
>> >>
>> >> I am quite sure there is a general lifetime/energy-width conversion
>> >> error
>> >> in Hephaestus: All core-hole lifetimes seem to come out too long by a
>> >> factor of - as it seems exactly - 10:
>> >> E.g. the lifetime of the F K-edge with a width of 0.25 eV is given as
>> >> 25.30 fs instead of ca. 2.6 fs (width = h_bar / lifetime).
>> >>
>> >> This glitch was present in 0.9.25 already and, as I noticed after
>> >> updating, prevails in 0.9.26. I have not tried earlier versions.
>> >>
>> >> Best regards,
>> >>
>> >> Daniel
>> >>
>> >> ___
>> >> 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-252-0431
>


-- 
--Matt Newville  630-252-0431
___
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] Core-hole Lifetimes in Hephaestus 0.9.26

2020-09-28 Thread Matt Newville
I believe it is using (or intends to use)

lifetime = hbar /gamma

which is what Krause et al give.  With gamma = 0.2 eV, and hbar ~=
4.13567e-15 eVs, then lifetime is ~20fs.
Maybe I'm missing something more subtle?  FWIW, these reported numbers for
gamma in eV are described by Krause et al as "FWHM".

--Matt


On Mon, Sep 28, 2020 at 1:13 PM Daniel Przyrembel <
daniel.przyrem...@fu-berlin.de> wrote:

> Hi Matt,
>
> Thanks for the quick reply!
> However, I seem to not have made clear my concern...
>
> The widths in energy (eV) are fine.
>
> However, in "Hephaestus", the "souped-up periodic table for the X-ray
> absorption spectroscopist", these level widths in energy (eV) are also
> given as equivalent lifetimes (in fs), however incorrectly: A level width
> of ~0.2 eV in fact corresponds to a lifetime of ca. 3 fs, not ~30 fs as
> given there.
>
> Those lifetimes shown in Hephaestus all seem to be off by a general factor
> of 10. I guess that is just the energy width/lifetime conversion gone
> slightly wrong...
> I imagine I'm not the only one using Hephaestus as a convenient tool to
> look stuff up quickly, so I thought it might be useful to point out this
> flaw.
>
> Just to make sure, I have again imported the xraydb: That has not changed
> Hephaestus' behavior in terms of the lifetime info (I'm using the latest
> 64-bit version on Windows).
>
>
> > Hi Daniel,
> >
> > Thanks - that does seem wrong.  FWIW, Larch uses XrayDB which uses
> > corehole
> > widths from Krause and Oliver for Z>10 and Keski-Rahkoken nand Krause for
> > Z<10.
> > For the F K edge, this give 0.2089 eV.  For this or other core-hole
> > widths,
> > and assuming you have Python installed, try:
> >
> >   ~> pip install xraydb
> >   ~> python
> >   >>> import xraydb
> >   >>> xraydb.core_width('F', 'K')
> >   0.2089
> >
> > Or install Larch and use
> >
> >~> larch
> >larch> core_width('F', 'K')
> >0.2089
> >
> >
> >
> > On Mon, Sep 28, 2020 at 12:08 PM Daniel Przyrembel <
> > daniel.przyrem...@fu-berlin.de> wrote:
> >
> >> To Whom it may concern,
> >>
> >> I am quite sure there is a general lifetime/energy-width conversion
> >> error
> >> in Hephaestus: All core-hole lifetimes seem to come out too long by a
> >> factor of - as it seems exactly - 10:
> >> E.g. the lifetime of the F K-edge with a width of 0.25 eV is given as
> >> 25.30 fs instead of ca. 2.6 fs (width = h_bar / lifetime).
> >>
> >> This glitch was present in 0.9.25 already and, as I noticed after
> >> updating, prevails in 0.9.26. I have not tried earlier versions.
> >>
> >> Best regards,
> >>
> >> Daniel
> >>
> >> ___
> >> 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-252-0431
___
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] Core-hole Lifetimes in Hephaestus 0.9.26

2020-09-28 Thread Matt Newville
Hi Daniel,

Thanks - that does seem wrong.  FWIW, Larch uses XrayDB which uses corehole
widths from Krause and Oliver for Z>10 and Keski-Rahkoken nand Krause for
Z<10.
For the F K edge, this give 0.2089 eV.  For this or other core-hole widths,
and assuming you have Python installed, try:

  ~> pip install xraydb
  ~> python
  >>> import xraydb
  >>> xraydb.core_width('F', 'K')
  0.2089

Or install Larch and use

   ~> larch
   larch> core_width('F', 'K')
   0.2089



On Mon, Sep 28, 2020 at 12:08 PM Daniel Przyrembel <
daniel.przyrem...@fu-berlin.de> wrote:

> To Whom it may concern,
>
> I am quite sure there is a general lifetime/energy-width conversion error
> in Hephaestus: All core-hole lifetimes seem to come out too long by a
> factor of - as it seems exactly - 10:
> E.g. the lifetime of the F K-edge with a width of 0.25 eV is given as
> 25.30 fs instead of ca. 2.6 fs (width = h_bar / lifetime).
>
> This glitch was present in 0.9.25 already and, as I noticed after
> updating, prevails in 0.9.26. I have not tried earlier versions.
>
> Best regards,
>
> Daniel
>
> ___
> 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 / webserver outage for upgrade

2020-09-09 Thread Matt Newville
Hi Folks,

The millenia.cars.aps.anl.gov server that hosts this website is going to be
upgraded to a new machine running a new OS later today.  This mailing list
and archives will be offline for a while - hopefully under one hour, but
these changes with web services can sometimes take longer.

In addition, I have not yet been able to get the Webatoms program running
on the new server yet.  I will try to solve this over the next few days.

--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] Unable to Import Data In Athena

2020-09-03 Thread Matt Newville
On Thu, Sep 3, 2020 at 10:11 AM Ravel, Bruce  wrote:

>
> Aha!  Attached log file.  Sorry.  Didn't notice that on my phone :(
>
> I concur with Matt about Larch.
>
> And at the risk of irking Matt, you could try forcing the use of
> Ifeffit.  While maybe not the best choice, it would isolate problems
> with Demeter from problems with Larch and your python installation.
>

You can use ifeffit.  It is just not supported and has known limitations
and problems that will not ever be fixed.
___
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] Unable to Import Data In Athena

2020-09-03 Thread Matt Newville
Hi Angshuman,

The logfile you attached says that Athena is using Larch and that is where
the error is coming from.
A few comments on that:
  a) it looks like it is using Python 2.7 which actually has not been
supported for xraylarch for some time now (well over a year)
  b) that the `pyfai` module is not installed, which should not be required
but is what is causing the actual error.

Having `pyfai` not installed should not cause an error, but this all
suggests that your xraylarch installation is quite all.
I would suggest reinstalling xraylarch using Python3 and see if that fixes
the problem.



On Thu, Sep 3, 2020 at 8:57 AM Angshuman Gupta 
wrote:

> Dear sir,
> I am new to this mailing list and excuse me if the question had already
> been asked. I am not able to import data in the Athena software. I tried to
> import some of the examples data like Fe_lepidocrocite.000 in the Fe
> standards folder while importing the data I encountered an error
> (screenshot has been attached along with the log file generated in the
> terminal).
> I am using Linux Mint 18.3 Sylvia OS and perl 5, version 22, subversion 1
> (v5.22.1).
> I followed the instruction for installation here "
> https://bruceravel.github.io/demeter/documents/SinglePage/demeter_nonroot.html
> "
> I will be thankful if you could suggest something to getting rid of this
> issue.
> Thank you
> Angshuman Gupta
> PhD scholar
> IIT Bombay
> ___
> 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] web apps for X-ray data and XAS library

2020-08-14 Thread Matt Newville
Hi Carlo,

Oops, that link for the XAS Data library should be
https://xaslib.xrayabsorption.org/elem/

On Fri, Aug 14, 2020 at 9:39 AM Matt Newville 
wrote:

> Hi Folks,
>
> I was fortunate enough to have a summer student this crazy summer and had
> them work (from home, of course!) on web applications for X-ray data
> resources, including absorption calculations for materials.  The result is
> a bit like a web version of Hephaestus and is currently at both
>https://xraydb.xrayabsorption.org/
> and
>https://millenia.cars.aps.anl.gov/xraydb/
>
> While similar to Hephaestus, there are some differences too. There are
> pages for absorption and fluorescence lines, absorption length
> calculations, ion chamber flux calculations, mirror reflectivities,
> scattering factors, and mono Darwin widths.  Many of the calculations will
> show interactive plots, links to data, and/or a link to a python script to
> reproduce the calculation.   Questions, comments, complaints, or
> suggestions for making this better are most welcome.  We may have missed
> your favorite Hephaestus feature - is so, please let us know.
>
> Also: the X-ray Data Library - a collection of XAS spectra - has moved to
>https://xaslib.xrayabsorption.org/ <https://xraydb.xrayabsorption.org/>
>
> This has also expanded some (well, now with about 270 spectra), and added
> several features, notably interactive plots.  Again, any comments or
> suggestions for making this better would be most welcome.   I will be
> adding more data to this library, but I also ask that if anyone has data
> they can and would like to share on this site, please let me know.
>
> Thanks for any feedback or suggestions you might have.
>
> --Matt
>
>

-- 
--Matt Newville  630-252-0431
___
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] web apps for X-ray data and XAS library

2020-08-14 Thread Matt Newville
Hi Folks,

I was fortunate enough to have a summer student this crazy summer and had
them work (from home, of course!) on web applications for X-ray data
resources, including absorption calculations for materials.  The result is
a bit like a web version of Hephaestus and is currently at both
   https://xraydb.xrayabsorption.org/
and
   https://millenia.cars.aps.anl.gov/xraydb/

While similar to Hephaestus, there are some differences too. There are
pages for absorption and fluorescence lines, absorption length
calculations, ion chamber flux calculations, mirror reflectivities,
scattering factors, and mono Darwin widths.  Many of the calculations will
show interactive plots, links to data, and/or a link to a python script to
reproduce the calculation.   Questions, comments, complaints, or
suggestions for making this better are most welcome.  We may have missed
your favorite Hephaestus feature - is so, please let us know.

Also: the X-ray Data Library - a collection of XAS spectra - has moved to
   https://xaslib.xrayabsorption.org/ 

This has also expanded some (well, now with about 270 spectra), and added
several features, notably interactive plots.  Again, any comments or
suggestions for making this better would be most welcome.   I will be
adding more data to this library, but I also ask that if anyone has data
they can and would like to share on this site, please let me know.

Thanks for any feedback or suggestions you might have.

--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] Jupyter/python question for Larch

2020-08-04 Thread Matt Newville
Hi Garret,


On Tue, Aug 4, 2020 at 9:55 AM Garret Bland  wrote:

> Hello!
>
> I have a Python/Larch related question. I have been developing some python
> script via jupyter and incorporating Larch as a module. I was able to read
> an athena prj file with the following code
>
> *import larch as lc*
>
> *athena_prj = lc.io.read_athena(prjfilename)*
>
> Python stores this object as a 'Group' object with each spectrum being an
> instance. I would like to go through more processing with all spectra.
>
> Example:
> *for spectrum in  athena_prj:*
> * lc.xafs.find_e0(spectrum.energy, spectrum.mu <http://spectrum.mu>,
> group = spectrum)*
>
> This does not work since the 'Group' object is not iterable. I tried to
> look up some other built-in functionality with python, but couldn't find an
> efficient way other than manually typing out each spectrum
> (athena_prj.spectrum1,  athena_prj.spectrum2,  etc). Is there any
> built-in functionality in larch that can iterate this 'Group' object?
>
>
Yeah, a Group is a pretty generic collection and so is not iterable.  There
is a dir() function, but that is not really what you want because the group
returned from read_athena() contains not only the "Athena Groups" (which is
what you want to loop over) but also some extra data about the project file
itself.   I think that what
you really want is to use the (magic-ish) `_athena_groups` data in the
project file group:

for spectrum_name, spectrum in athena.prj._athena_groups.items():
  lc.xafs.find_e0(spectrum.energy, spectrum.mu)

or if you're just looking to extract E0 for all the groups in the project
file, perhaps:

e0_vals = {name: lc.xafs.find_e0(spect) for name, spect in
athena_prj._athena_groups.items()}

--Matt

PS: sorry, the word 'group' here probably has four different meanings.
print(" ".join(["buffalo"]*8))!





Any help would be appreciated. Thank you for your time!
> Garret
>
> --
> Garret Bland
> PhD Student
> Carnegie Mellon University
> Civil and Environmental Engineering
> Porter Hall 201
> Pittsburgh, PA, 15213
> ___
> 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-252-0431
___
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] Reported W L3-edge and L2-edge energy

2020-05-07 Thread Matt Newville
Hi Mike, Matthew,


On Thu, May 7, 2020 at 5:55 PM Mike Massey  wrote:

> I agree Matthew, I also tend to use the primary K-edge peak for P
> calibration, but one issue to be wary of is attenuation/flattening of the
> primary peak (if one is using a concentrated sample).
>
> Gypsum sounds like a good material to use for S, since it is commonly
> available and probably not too variable. My material of choice for P
> (lazulite) might fail on both counts, so it might be a poor choice.
>
>
>
We're always on the lookout for better sulfur standards.  We find scotch
tape (magic tape that is), actually has pretty reproducible XANES and is
easy to come by.  Double-sided tape seems slightly different.

We tend to find gypsum slightly unreliable as a sulfur standard as there is
some variation in samples. Attached is a plot of 6 different gypsum samples
we've run (all in fluorescence), from a variety of user groups over a few
years.   You can see that there are differences in the low energy peaks and
large variations in the main sulfate peak intensity.  But the energy
position is stable.  Some of the variations may be due to over-absorption,
but the low-energy peaks suggest that "gypsum" is sometimes not high purity.

As I alluded to earlier, we never calibrate the energy at S, we just
measure it. We regularly check Fe and Cu.  These rarely vary by more than
0.5 eV unless we have "calibrated" to a
user-preferred-but-we-know-to-be-incorrect value, and we believe we have
the lattice constant pretty good to reproduce the Kraft values.   The
gypsum peak positions are pretty reliable and are definitely well below
2482 eV, more like 2481.75 eV.

For sure, we would be very interested in trying a Bond spectrometer like
Stumpfel et al user (or the clever Bond-like approach that Pettifer and
Hermes used before them).  We don't have a lot of room in our station for a
large diffractometer, but we do have access to area detectors these days,
so it is possible that multiple simultaneous reflections from fine Si
powder could be used.

--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] Reported W L3-edge and L2-edge energy

2020-05-07 Thread Matt Newville
Hi Mike,


On Tue, May 5, 2020 at 10:56 PM Mike Massey  wrote:

> On a tangentially related topic, I find that phosphorus K-edge XAS energy
> calibration conventions are still in a bit of a "Wild West" state, with a
> wide variety of materials and values in use for energy calibration. As an
> extreme example, one or two frequently cited papers in my field from the
> 2000s don't even report the material or value used for energy calibration,
> and only show portions of the spectra on an energy axis with values
> relative to an unknown E0.
>
>
I have never measured a P K edge, or indeed any edge lower in energy than
the S K edge (ignoring some X-ray raman work).  But if one is using a
Si(111) double-crystal monochromator where P or S is approximately the
low-energy (high-angle) limit, then it really should be that the
calibration does not drift much and cannot be too wrong at low energies.

That is, a mono calibration is controlled by a d-spacing and angular
offset. Normally (or perhaps, in my experience), "re-calibrating" is done
by changing the angular offset, leaving the d-spacing alone.  That is, the
d-spacing is presumably known, at least to within some thermal drift.
If that is the case that the d-spacing really is not changing and what
needs to be refined is the angular offset, then setting the offset at
relatively high energy edges will be much more sensitive, and changing the
angular offset to that a high-energy edge is correct should move lower
energy edges by a smaller amount.   The corollary is that you have to move
the offset a lot to move the P  K edge around, and that would have a larger
(and ever-increasing) impact on higher energy edges such as Ca, Fe, Cu or
Mo.

The counter-argument is also true:  d-spacing has a bigger effect on the
high-angle / low-energy edges.

So, if you believe the mono d-spacing (or you believe the beamline
scientist who believes it ;)) then calibrate at the highest energy you
can.   The Kraft values don't go very low in energy.

All that said, if using a different mono crystal such as InSb or more
exotic crystals, I have no idea how stable those are.


I too have picked my own material and value, and will be the first to
> acknowledge that I did so out of necessity and ease of comparison to other
> available data, rather than because I thought it was correct.
>
> The issue of calibration conventions and values definitely seems to be one
> that merits continued discussion. It has been interesting to watch things
> evolve over time in the case of iron, for example (it's good to know that
> 7110.75 is a candidate calibration value...) I appreciate Matt's detailed
> thoughts, and the data that he's been working with. Thanks Matt!
>
>
Cheers,
>
>
>
> Mike
>
>
>
>
>
> On May 6, 2020, at 3:32 PM, Matt Newville 
> wrote:
>
> 
> Hi Simon,
>
> This is definitely a timely discussion for me, as I've been spending part
> of the quartine working on collating data and expanding datasets for an
> XAFS spectral database.  I'm hoping to have something ready for public
> comment and to start asking for contributions of data in a few weeks, but
> I'll be happy to have more discussion about that sooner too.
>
> I generally believe that the monochromator I use at GSECARS is both
> well-calibrated and reasonably accurate.  That is, with 2 angular encoders
> with a resolution of >130,000 lines per degree and an air-bearing, I
> believe the angular accuracy and repeatability are very good.  I believe
> there are equally good moons in existence.   As Matthew Marcus pointed to
> the Kraft paper (which used an older source but 4-bounce mono to improve
> resolution), we find that Fe foil is definitely better defined as 7110.75
> and Cu foil is between 8980.0 and 8980.5 eV.  That is, we've measured
> multiple foils, found their first derivatives, and refined the d-spacing
> and angular offset.  We do this about once per run, and the offsets tend to
> be very consistent.   For sure, there is some question about whether the
> Kraft numbers are perfect.   For sure, putting Fe foil at 7110.75 +/- 0.25
> eV appears to be "most right" to us.
>
> I also believe that we should probably re-measure these metal foils (and
> other compounds) with a single calibration set for both Si(111) and
> Si(311).  We will probably have time to do that this summer in the time
> between "beamline staff can get back to the beamline" and "open for outside
> users".
>
> What I can tell you now is:  I have some data on W metal, WO2, and WO3
> measured all at the same time on our bending magnet line, with Si(111).  An
> Athena project for this is attached (W.prj).   I cannot vouch for the
> absolute calibration.
>
> I also attach a set of foils (V, Fe, Cu, Mo) measured wit

Re: [Ifeffit] Change in fixed baseline after fit in XAS Viewer

2020-05-04 Thread Matt Newville
Hi George,



On Mon, May 4, 2020 at 12:25 PM George Sterbinsky <
georgesterbin...@u.northwestern.edu> wrote:

> Hello,
>
> I have observed changes in fixed parameters while running a pre-edge peak
> fit in XAS Viewer. I first run a baseline fit. This provides a good match
> to the data in the baseline fitting region. I would like to subtract the
> baseline from the data and then numerically integrate the data. In order to
> export the baseline fit and data, I fix all of the fitting parameters for
> bline and bpeak and then click "fit model". This generates a baseline and
> fit that no longer match the data well in the baseline fitting region.
> Additionally, in the "Fit Results" window, the reported best-fit values of
> the fixed parameters are slightly different from the values reported in the
> "Value" field after the baseline fit, to which they were fixed. This
> appears to be the result of rounding of the baseline fit parameters at some
> point after the baseline fit. For example bline_slope was fixed to
> "-0.0024752483" but the best-fit value is "-0.00247500". I realize I am
> using XAS Viewer in a way that it was not exactly designed for, and perhaps
> no one anticipated someone fixing a parameter out to 10 decimal places.
> However, what I am doing still seems reasonable, and I would greatly
> appreciate it if XAS Viewer could be updated so that all digits entered in
> the Value field for a fixed parameter will be maintained for the fit. I am
> happy to provide a project file and instructions to reproduce my
> observation if they would be helpful.
>
>
When you do "Fit Model", the fit will not ignore the "pre-edge peak
range".   So, if you just have a baseline, that could definitely change the
resulting baseline "Lorentzian + Line". Could that be what you're seeing?

FWIW, it should definitely be possible to fix the baseline (even if that
might not always be ideal) parameters after just fitting the baseline.  It
seems like that works to me, but I only tried for one test case.

I can definitely believe that there is some loss of precision when copy
parameters from "best fit" values.

It might be helpful to extract the extra-verbose Larch script (Ctrl-l to
bring up the Larch buffer, the Ctrl-s to save the session history) and send
that.

--Matt

PS: I can also see that it would be nice to report things like

   Area of data, Area of data - baseline, Area of Peaks (other than
baseline)

in addition to Peak centroid.   The Area of the Peaks is just the sum of
the peak amplitudes (as the peak functions are all unit normalized), but it
would be nicer to do that in a way that included the propagation or
uncertainties (including correlations).
___
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 XAS Viewer

2020-05-04 Thread Matt Newville
On Mon, May 4, 2020 at 12:55 PM Xinyue Wang  wrote:

> Hi Matt,
>
> I am trying to fit the main peak. So, to do the general peak fitting,
> should I use the pre-edge peak tab in XAS viewer or other tab?
> Thanks for your help.
>
>
What sort of model do you want to use to fit the main peak?  If you want to
fit it with some pre-defined line shapes (arctan, Gaussians, etc), then the
pre-peak tab might be able to do that.  As I mentioned earlier, you'll have
to start with "fit baseline" to get started even though it is basically
inappropriate, and then modify the model.

I should say that I'm not entirely sure that fitting in this way is really
what you want to do, but maybe you have some ideas about that is the
approach you want to use.

--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 with XAS Viewer

2020-05-03 Thread Matt Newville
On Sat, May 2, 2020 at 3:18 PM Xinyue Wang  wrote:

> Hi Matt,
>
> Thanks for your detailed instructions. I am just trying to follow the
> steps and see how it works. I am not trying to do complicated things.
> My issue is I would expect the grey vertical lines after press the "Fit
> Baseline" button, but nothing shows up. I tried to select a
> larger region(which was not pre-peak), also nothing happened. So I am
> confused.
>

>From what I saw of your screenshot (not much to go on, really), it was not
obvious that your data has much (possibly "any") pre-edge data.  It also
shows as "scaled y" vs "x", which suggests that the data wasn't even read
in as XAS data.


Besides, can I use the XAS Viewer to do main peak fitting?
>

Well, I guess another way to put that is: yes, you probably can use XAS
Viewer to do general-purpose peak-fitting.  It is not really designed for
that, but you might be able to make that work.  If that is what you want to
do.   Is that what you are trying to do?

I know that Larch has its own language based on python. I am wondering can
> I use larch function, like fitting peaks in Jupiter Notebook?
>

You can use larch as a Python library, or use the lmfit Python library to
do the fitting.   Some Larch functionality, notably the plotting and GUI
aspects, may not work well from a Jupyter notebook.

If you're using Python or Jupyter notebook, you probably don't really need
to use the Larch language for most XAS processing and analysis
functionality.

Hope that helps,

--Matt

PS:  I should say that if one is really doing Feff-based fitting with
`feffit()`,  it is still really, really helpful to create a
`larch.Interpreter()` and pass that around to all of the corresponding
functions.   Over the past year or so, this requirement has been removed
from most of the Larch functions but the functions for doing Feff-based
fitting are more intertwined and so keep some "state information" within a
"session".  But that seems separate from the question here.
___
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 XAS Viewer

2020-05-02 Thread Matt Newville
Hi Xinyue,

On Fri, May 1, 2020 at 9:16 PM Xinyue Wang  wrote:

> Hi,
>
> I am Xinyue, a student who interested in using XAS Viewer. My issue is
> when I tried baseline fitting, I followed the document. But there was no
> region, no centroid, and no fitting line shown. Here is a screenshot of my
> work. Could you please help me with this?
> Thanks for your help.
>

It's hard to tell from the screenshot alone.  Just to clarify, the idea for
the panel is to fit pre-edge peaks to known lineshapes (Gaussian,
Lorentzian, Voigt, etc).  The interface could probably be used for
general-purpose curve-fitting of many kinds of spectra, but right now it
definitely skews to pre-edge peak fitting.

Because of that emphasis, the idea is to first press the "Fit Baseline"
button -- this will do a crude fit of a Lorentzian + Line that are meant to
represent any residual background and the main absorption edge.  The fit
for this baseline is done over the energy range defined by "Fit Energy
Range" but ignoring the "Pre-edge Peak Range", which is meant to be the
portion of the XAS spectra where the pre-edge peaks are. That is, this
baseline fit should
look something like Figure 5.4.2 at
https://xraypy.github.io/xraylarch/xasviewer/index.html#pre-edge-peak-fitting.
In that figure, the black dots show the ends of the Pre-edge Peak Range
that is ignored in this baseline fit.   For sure, the initial guess for
this range may not be very good.  But it is easy to refine this ignored
range.  It is also not actually critical to get this baseline fit perfect -
it's just a place to start the fits of the peaks themselves, and the
remaining fits will refine the baseline as well as the peaks over the full
energy range. After a baseline fit is done, you can add peaks and then
use the "Fit Model", which fits over the whole "Fit Energy Range",
ignoring the "Pre-edge Peak Range".

>From your screenshot, I don't see much of a pre-edge and not many obvious
peaks.  The result is that the actual fit energy range for the baseline
(that is
"Fit Energy Range" - "Pre-edge Peak Range") is very short.  I can believe
the fit will fail under those conditions.  But I sort of think that failure
really comes because your data doesn't have pre-edge peaks.

Maybe you are trying to do something more complicated?

--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] unable to export xdi file in xas viewer

2020-05-01 Thread Matt Newville
Hi George,


On Thu, Apr 30, 2020 at 11:39 PM George Sterbinsky <
georgesterbin...@u.northwestern.edu> wrote:

> Hi Matt,
>
> Thank you, it is now working for me too. In your previous email, you said,
> "It probably should not even be trying to estimate the uncertainty in the
> model." Why do you say that? Having the uncertainty in the fit parameters,
> and therefore the centroid, could seemingly be useful.
>
>
Sorry for the delay in answering...

I think the problem you were seeing was because uncertainties in fitted
parameters were not estimated.  Sometimes that happens, say if some
parameter doesn't actually alter the fit or gets stuck at a boundary or
something like that. That case is not ideal, but it should be
acceptable - and definitely not cause problems.

After a fit is done, the code tries to evaluate the uncertainties in the
best-fit, per point `delta_fit` so that one would be able to plot bands of
uncertainty (such as
https://lmfit.github.io/lmfit-py/examples/documentation/model_uncertainty.html).
 Of course, to calculate that `delta_fit`, it needs uncertainties in the
parameters.  The error you were seeing wat that it could not do this
calculation because, for some reason, it did not have those uncertainties.
So, what I meant was that the code should not be trying to estimate that
`delta_fit` if it doesn't have uncertainties in the parameters.

--Matt








George
>
> On Wed, Apr 29, 2020 at 12:05 PM Matt Newville 
> wrote:
>
>> Hi George,
>>
>> Very sorry, that should have been
>>  delta_fit = 0.0*result.best_fit
>> It's now fixed in github master, and I verified that I could actually
>> export a model from pre-edge peak fitting in XAS_Viewer.
>>
>>
>>
>> On Wed, Apr 29, 2020 at 10:31 AM George Sterbinsky <
>> georgesterbin...@u.northwestern.edu> wrote:
>>
>>> Hi Matt and all,
>>>
>>> Unfortunately, after a clean install of larch following the source
>>> installation instructions, I am not able export any fits to xdi files, and
>>> a different error, shown below, is now printed in the terminal. Please let
>>> me know if any additional information would be helpful in solving this
>>> issue.
>>>
>>> Thank you,
>>> George
>>>
>>>
>>> Traceback (most recent call last):
>>>   File
>>> "/opt/anaconda3/lib/python3.7/site-packages/xraylarch-0.9.47-py3.7.egg/larch/wxxas/prepeak_panel.py",
>>> line 366, in onExportFitResult
>>> yerr=yerr, x=x)
>>>   File
>>> "/opt/anaconda3/lib/python3.7/site-packages/xraylarch-0.9.47-py3.7.egg/larch/io/export_modelresult.py",
>>> line 59, in export_modelresult
>>> delta_fit = 0.0*result_best_fit
>>> NameError: name 'result_best_fit' is not defined
>>>
>>>
>>>
>>>
>>> On Tue, Apr 21, 2020 at 9:25 AM Matt Newville <
>>> newvi...@cars.uchicago.edu> wrote:
>>>
>>>> Hi George,
>>>>
>>>> Hm, sorry about that.  It seems to be saying that the parameter
>>>> uncertainties weren't calculated correctly.  It probably should not even be
>>>> trying to estimate the uncertainty in the model.  I believe it should be
>>>> fixed in git master for larch, and I'll see about looking for this in lmfit
>>>> too.
>>>>
>>>> On Mon, Apr 20, 2020 at 4:00 PM George Sterbinsky <
>>>> georgesterbin...@u.northwestern.edu> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> When attempting to export an xdi file for a pre-edge peak fit in XAS
>>>>> viewer, the error message below prints to the terminal and the xdi file is
>>>>> not generated. I can provide the project file and instructions for
>>>>> generating the error message if that would be helpful.
>>>>>
>>>>> Thank you,
>>>>> George
>>>>>
>>>>>
>>>>> Traceback (most recent call last):
>>>>>   File
>>>>> "/anaconda3/lib/python3.7/site-packages/larch/wxxas/prepeak_panel.py", 
>>>>> line
>>>>> 369, in onExportFitResult
>>>>> yerr=yerr, x=x)
>>>>>   File
>>>>> "/anaconda3/lib/python3.7/site-packages/larch/io/export_modelresult.py",
>>>>> line 60, in export_modelresult
>>>>> delta_fit = result.eval_uncertainty(result.params, **kwargs)
>>>>>   File "/anaconda3/lib/python3.7/site-packages/lmfit/model.py", line
>>>

Re: [Ifeffit] unable to export xdi file in xas viewer

2020-04-29 Thread Matt Newville
Hi George,

Very sorry, that should have been
 delta_fit = 0.0*result.best_fit
It's now fixed in github master, and I verified that I could actually
export a model from pre-edge peak fitting in XAS_Viewer.



On Wed, Apr 29, 2020 at 10:31 AM George Sterbinsky <
georgesterbin...@u.northwestern.edu> wrote:

> Hi Matt and all,
>
> Unfortunately, after a clean install of larch following the source
> installation instructions, I am not able export any fits to xdi files, and
> a different error, shown below, is now printed in the terminal. Please let
> me know if any additional information would be helpful in solving this
> issue.
>
> Thank you,
> George
>
>
> Traceback (most recent call last):
>   File
> "/opt/anaconda3/lib/python3.7/site-packages/xraylarch-0.9.47-py3.7.egg/larch/wxxas/prepeak_panel.py",
> line 366, in onExportFitResult
> yerr=yerr, x=x)
>   File
> "/opt/anaconda3/lib/python3.7/site-packages/xraylarch-0.9.47-py3.7.egg/larch/io/export_modelresult.py",
> line 59, in export_modelresult
> delta_fit = 0.0*result_best_fit
> NameError: name 'result_best_fit' is not defined
>
>
>
>
> On Tue, Apr 21, 2020 at 9:25 AM Matt Newville 
> wrote:
>
>> Hi George,
>>
>> Hm, sorry about that.  It seems to be saying that the parameter
>> uncertainties weren't calculated correctly.  It probably should not even be
>> trying to estimate the uncertainty in the model.  I believe it should be
>> fixed in git master for larch, and I'll see about looking for this in lmfit
>> too.
>>
>> On Mon, Apr 20, 2020 at 4:00 PM George Sterbinsky <
>> georgesterbin...@u.northwestern.edu> wrote:
>>
>>> Hello,
>>>
>>> When attempting to export an xdi file for a pre-edge peak fit in XAS
>>> viewer, the error message below prints to the terminal and the xdi file is
>>> not generated. I can provide the project file and instructions for
>>> generating the error message if that would be helpful.
>>>
>>> Thank you,
>>> George
>>>
>>>
>>> Traceback (most recent call last):
>>>   File
>>> "/anaconda3/lib/python3.7/site-packages/larch/wxxas/prepeak_panel.py", line
>>> 369, in onExportFitResult
>>> yerr=yerr, x=x)
>>>   File
>>> "/anaconda3/lib/python3.7/site-packages/larch/io/export_modelresult.py",
>>> line 60, in export_modelresult
>>> delta_fit = result.eval_uncertainty(result.params, **kwargs)
>>>   File "/anaconda3/lib/python3.7/site-packages/lmfit/model.py", line
>>> 1488, in eval_uncertainty
>>> dval = pars[pname].stderr/3.0
>>> TypeError: unsupported operand type(s) for /: 'NoneType' and 'float'
>>> ___
>>> 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-252-0431
>> ___
>> 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-252-0431
___
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 Artemis handle crystal structure data with partial occupancy in vorlanite (cubic CaUO4)

2020-04-28 Thread Matt Newville
Hi Dien,

Yes, basically Artemis / Atoms cannot handle partial occupancy for
crystallographic sites because partial occupancy is not readily translated
to a cluster of atoms.  So, what you have to do is start with a CIF without
fractional occupancy, say that has only Ca or only U in that site, and
generate a cluster of atoms from it.  Then, you can (and here, have to)
edit that cluster of atoms to replace some of the Ca/U with U/Ca.  Which
ones, and how many, is up to you.

--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] unable to export xdi file in xas viewer

2020-04-21 Thread Matt Newville
Hi George,

Hm, sorry about that.  It seems to be saying that the parameter
uncertainties weren't calculated correctly.  It probably should not even be
trying to estimate the uncertainty in the model.  I believe it should be
fixed in git master for larch, and I'll see about looking for this in lmfit
too.

On Mon, Apr 20, 2020 at 4:00 PM George Sterbinsky <
georgesterbin...@u.northwestern.edu> wrote:

> Hello,
>
> When attempting to export an xdi file for a pre-edge peak fit in XAS
> viewer, the error message below prints to the terminal and the xdi file is
> not generated. I can provide the project file and instructions for
> generating the error message if that would be helpful.
>
> Thank you,
> George
>
>
> Traceback (most recent call last):
>   File
> "/anaconda3/lib/python3.7/site-packages/larch/wxxas/prepeak_panel.py", line
> 369, in onExportFitResult
> yerr=yerr, x=x)
>   File
> "/anaconda3/lib/python3.7/site-packages/larch/io/export_modelresult.py",
> line 60, in export_modelresult
> delta_fit = result.eval_uncertainty(result.params, **kwargs)
>   File "/anaconda3/lib/python3.7/site-packages/lmfit/model.py", line 1488,
> in eval_uncertainty
> dval = pars[pname].stderr/3.0
> TypeError: unsupported operand type(s) for /: 'NoneType' and 'float'
> ___
> 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-252-0431
___
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.47

2020-04-18 Thread Matt Newville
Hi George,

Sorry for the trouble.  I think a fresh install is not the only option, but
it might be the simplest ;).  It seems there were some challenges with
using conda to update, including that it sometimes just seems to take
forever.   I'm not sure what to do about that.

I think pip install should work, but you may need to manually blow away
some of the installed folders in "python3.7/site-packages", as there can be
confusion about where the newly installed packages go based on the
installation method (that this, there might be a folder called 'larch' and
there might be one called 'xraylarch-0.9.45-py3.7.egg', and similarly for
other packages.   You could just blow away (a partial list, and maybe not
exhaustive, but ones that I know were changed between 0.9.45. and 0.947 and
potentially causing confusion), these folders under
python3.7/site-packages/  in your installation:
   larch
   xraylarch*
   pyepics*
   epics
   pyshortcuts*
   wxmplot*
   lmfit*
   silx*
   uncertainties*

Then a fresh `pip install xraylarch` should work.  If you try that and
still run into problems, please let me know what you see.

--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] [EXTERNAL] Ifeffit Digest, Vol 206, Issue 8

2020-04-13 Thread Matt Newville
Hi Dien,

On Mon, Apr 13, 2020 at 2:02 PM dien...@srnl.doe.gov 
wrote:

> Hi, all
>
> I fitted my Cr EXAFS data, but E0 was -2.5. I calibrated the spectrum in
> energy space by +10 eV, the spectra in K and R space were identical before
> and after this calibration, in contract to my understanding that the k
> space oscillations and R magnitude should shift. Could you please provide
> any direction on how to get E0 to position values or negative E0 is
> acceptable? Thank you so much.
>
>
An E0 of -2.5 eV should not be a problem.  Basically, E0 gets selected for
an experimental spectrum in a pretty ad-hoc way (maximum of the 1st
derivative).   The Feff calculations also make an assumption about where
the energy threshold should be.  It's not unusual or a problem for these to
differ by a few eV.   We would start to get concerned if the difference
needed to be as large as 10 eV.  Now, sometimes that is reasonable, but it
can also indicate that the ligand or bond length is way off.

I don't know what you mean by "calibrated the spectrum in energy space
by +10 eV" -- you mean you added the number 10 to all energy points?  That
won't make a difference.

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] errors in bond lengths

2020-04-12 Thread Matt Newville
Hi George,

I think this will not be a different answer from Matthew's or Anatoly's
answers, but just reiterate their points.  The Purans et al 2008 PRL from
2008 appears to use both non-linear fitting with Feff and EDA (which should
give basically the same results as Artemis/Ifeffit/Larch, though I do not
know in detail what error analysis is done), and the log-ratio method.  I
think they also fit the resulting sigma2 (derived from the non-linear fit)
to an Einstein model.

The log-ratio method can only determine relative changes in distance,
coordination number, and sigma2.  The main motivation for using this method
is that scattering factors in the EXAFS equation will cancel out (or mostly
cancel out) when comparing two similar experimental spectra.  In addition,
it is often argued that data extraction errors (energy scale, background
subtraction, etc) would tend to be the same for two experimental spectra
and so would also mostly cancel out.  There usually isn't much analysis of
what residual systematic errors happen with the log-ratio method.   The
working idea is that the ratio of the log of isolated single-shell EXAFS
chi(k) (or what we would call chi(q) in Artemis/Ifeffit/Larch)  amplitudes
vs k**2 should be linear (intercept = Delta N, slope=Delta sigma2) and the
phase difference vs k should also be linear (intercept=0 if E0 is truly
unchanged, and slope = Delta R).   For anyone who actually plots those
(even for spectra on the same sample), you will probably find that these
are "linear-ish", clearly showing both "yeah, that could work" and also
"maybe not perfectly".

But, if I'm reading this PRL correctly, it looks like they use the
log-ratio method to compare sigma2 and R of spectra at the same temperature
but with different isotopes. That does seem like a fine way to better
determine the subtle differences between those spectra.

--Matt


On Sat, Apr 11, 2020 at 12:41 PM George Sterbinsky <
georgesterbin...@u.northwestern.edu> wrote:

> Hello,
>
> As is well known, EXAFS is more accurate at determining relative changes
> in bond lengths than absolute changes in bond lengths due to cancelation of
> systematic errors in relative comparisons. When comparing the relative
> changes in bond lengths determined from EXAFS fits, as one might for a
> temperature series for example, is it appropriate to use the uncertainties
> returned by Artemis?
>
> My question arises in part from Phys Rev Lett vol. 100 pg. 055901 (2008),
> where the authors state that errors for changes in bond length in a
> temperature series were determined by empirical means rather than
> statistical means. This then raises the question as to if the authors
> believe that statistical means would overestimate the error. My inclination
> is to think that the uncertainties reported by Artemis would be appropriate
> because of the scaling by the square root of reduced chi squared. However,
> I want to see what others think about this before committing to it.
>
> Thank you,
> George
>
> ___
> 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] larch can not deconvolve my data

2020-04-09 Thread Matt Newville
Hi Shaofeng,

Sorry for the trouble.  It turns out that the energy array for that
spectrum had two energy points that were different by 0.001 eV.That's
not that uncommon, really.  But deconvolution needs to interpolate the data
onto a uniform energy grid, and it was using the smallest difference as the
energy step size. That made the array size very large, and the
deconvolution was just taking forever.

I have fixed the deconvolution code to better guard against absurdly tiny
energy steps or very large arrays.  But it will be a little while before I
make another release, so I also attach a project file where I moved the
energy values for the two offending points so that they are different by
0.05 eV.I think that should work for you with the latest released
code.

Cheers,





On Thu, Apr 9, 2020 at 8:36 PM Shaofeng Wang  wrote:

> Dear all,
>
> Recently I am trying to deconvolve a As K-edge xafs data using larch. But
> the xas viewer program always crash. I tried other K edge spetra, it worked
> well. I attached my data, please give me some help.
>
>
>
>
>
>
> 祝
> 好运!
> Best regards,
>
> 王少锋,Shaofeng Wang, Ph.D
> 中国科学院沈阳应用生态研究所,Institute of Applied Ecology, CAS
> Email: wangshaof...@iae.ac.cn; sf.w...@hotmail.com
> Address: Wenhua Road 72, Shenyang
>
>
> ___
> 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-252-0431


S_Wang.prj
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] Unable to access content on millenia.cars.aps.anl.gov website

2020-03-09 Thread Matt Newville
Hi Julietta.



On Mon, Mar 9, 2020 at 10:41 AM Jullieta Lum  wrote:

> Good Day,
>
> I need assistance with accessing content on the iffefit website. I am
> subscribed to the mail list and receive the digest. However, I am unable to
> open any of the past questions and answers which I could do before.
>
>
Sorry for the trouble.   My guess is that you are being bitten by the
recent "https" requirement for all websites hosted at Argonne Lab.  This is
completely out of my control, and means that any address like

   http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

should be replaced with (note: "https" in place of "http"):

   https://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

It's basically impossible to change all the links that are out there in the
wild (but I should do a better job of updating the links on millenia
itself!)

But also: it seems that most browsers will usually know to auto-magically
translate links once you have gone to the "https" version.

hope that helps,

--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] Larch 0.9.47

2020-03-03 Thread Matt Newville
Hi Garret,


On Tue, Mar 3, 2020 at 8:01 AM Garret Bland  wrote:

> Hi All,
> I tried to reinstall anaconda (Windows 10) and create a new environment to
> install the newest version of larch. It gave me the following error:
>
> conda install -yc GSECARS xraylarch
> Collecting package metadata (current_repodata.json): done
> Solving environment: failed with initial frozen solve. Retrying with
> flexible solve.
> Solving environment: failed with repodata from current_repodata.json, will
> retry with next repodata source.
> Collecting package metadata (repodata.json): done
> Solving environment: failed with initial frozen solve. Retrying with
> flexible solve.
> Solving environment: -
> Found conflicts! Looking for incompatible packages.
> This can take several minutes.  Press CTRL-C to abort.
> failed
>

Sorry for the trouble.  It seems like updating from a previous release is
not working as well as I hoped.  I'm not sure what that error *really*
means, but I have also seen some Anaconda environments be either very, very
slow to "solve environment" or fail when I'm pretty sure it really should
succeed.

Slightly conda-specific, but: It should definitely be the case that doing
an "conda update --all" or making a completely new environment and
installing into that should work too.  I'm reluctant to expect most users
to have to install / update with conda, but I also think it should work.

>
> I then installed pip on my virtual environment and used pip install
> xraylarch. That seemed to work for me.
>

OK, yes.  For the Python-enabled users, `pip install xraylarch` should work
for most work (including all the XAFS functionality).  It will not install
some optional packages (notably tomopy), but that should be OK unless
you're doing fluorescence tomography.

Just for completeness and to prove that all three systems have their own
challenges, `pip install xraylarch` will work on Windows and MacOS, but
will work on Linux only if wxPython has already somehow been installed.  A
binary package is not available for "Linux" and compiling from source on
Linux is not trivial (these two things are related).

Anyway, I'm glad to hear you've got something working.

--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.47

2020-03-02 Thread Matt Newville
Hi Stefan, Edmund,

Thanks - and sorry that the update didn't work.  I think I understand why
that is, as I took out some "requirements" for the conda package.  I will
update that package to put the pyepics requirement back in, especially as
it really needs to be updated since Python 3.7.6 broke pyepics (no,
really... long story, and we have a work-around).  I do think that doing a
"conda update --all" might have worked, but re-installing is probably the
safest bet.



On Mon, Mar 2, 2020 at 3:54 AM Edmund Welter  wrote:

> Dear Matt, Stefan,
>
> I fear it is the same on my Ubuntu 16.04 desktop. After updating I get the
> error messages shown in the attached text file when i try to start larch in
> the terminal.
>
> Cheers,
>
> Edmund
>
>
> On 02.03.20 10:36, Mangold, Stefan (IPS) wrote:
>
> Dear all,
>
> tried the upgrade under anaconda3, on MacOs10.12.6. after the upgrade
> nothing worked any more
>
> did the following steps:
>
> conda update --all
> conda install -yc GSECARS xraylarch
> larch -m
>
> and
> pip install pyshortcuts==1.4
> larch -m
>
> nothing worked anymore. It worked again after a complete delete and
> re-install of the actual version of anaconda3
>
> Best regards
>
> Stefan Mangold
>
> Am 28.02.2020 um 21:53 schrieb Matt Newville :
>
> Hi Everyone,
>
> Larch 0.9.47 is now available, with installers and source code at
> https://xraypy.github.io/xraylarch/installation.html.   For python users,
> there is a plain python package available on PyPI and conda packages for 
> Anaconda
> Python.  See the installation docs for more details.
>
> There have been several improvements and bug fixes, especially for the XAS
> Viewer application and for XRF modeling in the nearly six months since the
> last release.  In particular, there have been two improvements to basic
> XAFS and XANES data processing, both based on user reports and comparisons
> to older versions of Ifeffit/Athena and give a noticeable change in XAFS
> and XANES processing.
>
> First, the ranges used in by the pre_edge() function for finding the edge
> step for normalization are now better determined from the actual data range
> rather than simply being hard-wired numbers.  These improvements were long
> over-due and give noticeably better default results for XANES data,
> especially for relatively low-energy edges such as S and Cl K edges.
>
> When reading Athena Project files (say, to import into XAS Viewer), the
> pre-edge and normalization ranges from the Athena Project file will be
> preserved.  When reading in new raw data, or if you select the "Use Default
> Setting" button on the Normalization Panel for any group in XAS Viewer, the
> newer defaults will be used.   You can always alter these values, but in
> playing around with this with a range of datasets, the new defaults seem to
> give a noticeable improvement in almost all cases and rarely bad.
>
> Second, as a few users have pointed out or gently hinted at over many
> months, there were sometimes significant differences in the background
> removals between classic Autobk/Ifeffit/Athena and Larch, with Larch
> sometimes being noticeably and inexplicably worse. I believe this involved
> two different problems.  One was introduced a while back when implementing
> an estimate of delta_chi - the variance in chi due to the background
> subtraction. This estimate is important, but I botched some of the
> configurations of the number of knots, fit range, and Rbkg. The other
> problem was that "spline clamps" were just done too differently in Larch
> and Ifeffit/Athena.
>
> I believe this is now working much better: the background results are much
> more consistent, and do not occasionally get "very bad".  They also happen
> to be generally closer to Autobk/Ifeffit/Athena, and perhaps slightly
> better because the fit range in R-space is now more consistently determined
> (instead of wandering +/- a few R data points around Rbkg where the misfit
> will often be the largest). In addition, `delta_chi` (never calculated in
> Ifeffit/Athena) is now also more consistent.  One consequence of this
> change is that a very small change in Rbkg (of say 0.01 to 0.05 Ang) may
> actually give no difference at all in mu0(E) or in chi(k).
>
> I bring these changes up because I think they will be noticeable.  I think
> they are both improvements, but let me know if you find cases for which you
> think are now made worse.   Possibly related: one thing that I definitely
> noticed in going through several example data sets was that I tended to
> favor a k-weight of 2 instead of 1 for background subtraction -- so much so
> that it seemed like this might be a better de

[Ifeffit] Larch 0.9.47

2020-02-28 Thread Matt Newville
Hi Everyone,

Larch 0.9.47 is now available, with installers and source code at
https://xraypy.github.io/xraylarch/installation.html.   For python users,
there is a plain python package available on PyPI and conda packages
for Anaconda
Python.  See the installation docs for more details.

There have been several improvements and bug fixes, especially for the XAS
Viewer application and for XRF modeling in the nearly six months since the
last release.  In particular, there have been two improvements to basic
XAFS and XANES data processing, both based on user reports and comparisons
to older versions of Ifeffit/Athena and give a noticeable change in XAFS
and XANES processing.

First, the ranges used in by the pre_edge() function for finding the edge
step for normalization are now better determined from the actual data range
rather than simply being hard-wired numbers.  These improvements were long
over-due and give noticeably better default results for XANES data,
especially for relatively low-energy edges such as S and Cl K edges.

When reading Athena Project files (say, to import into XAS Viewer), the
pre-edge and normalization ranges from the Athena Project file will be
preserved.  When reading in new raw data, or if you select the "Use Default
Setting" button on the Normalization Panel for any group in XAS Viewer, the
newer defaults will be used.   You can always alter these values, but in
playing around with this with a range of datasets, the new defaults seem to
give a noticeable improvement in almost all cases and rarely bad.

Second, as a few users have pointed out or gently hinted at over many
months, there were sometimes significant differences in the background
removals between classic Autobk/Ifeffit/Athena and Larch, with Larch
sometimes being noticeably and inexplicably worse. I believe this involved
two different problems.  One was introduced a while back when implementing
an estimate of delta_chi - the variance in chi due to the background
subtraction. This estimate is important, but I botched some of the
configurations of the number of knots, fit range, and Rbkg. The other
problem was that "spline clamps" were just done too differently in Larch
and Ifeffit/Athena.

I believe this is now working much better: the background results are much
more consistent, and do not occasionally get "very bad".  They also happen
to be generally closer to Autobk/Ifeffit/Athena, and perhaps slightly
better because the fit range in R-space is now more consistently determined
(instead of wandering +/- a few R data points around Rbkg where the misfit
will often be the largest). In addition, `delta_chi` (never calculated in
Ifeffit/Athena) is now also more consistent.  One consequence of this
change is that a very small change in Rbkg (of say 0.01 to 0.05 Ang) may
actually give no difference at all in mu0(E) or in chi(k).

I bring these changes up because I think they will be noticeable.  I think
they are both improvements, but let me know if you find cases for which you
think are now made worse.   Possibly related: one thing that I definitely
noticed in going through several example data sets was that I tended to
favor a k-weight of 2 instead of 1 for background subtraction -- so much so
that it seemed like this might be a better default.  I did not change this
default yet, but if you have a strong opinion on this, that might be a good
topic for discussion here.

There are some documentation improvements, but this is an ongoing process
and never complete.  It is also one area where help and feedback would
greatly be appreciated.  If you or your students have time to work through
the larch examples and/or documentation and make improvements or even
suggestions for improvements in readability or completeness, it would be
greatly appreciated.

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] XAFS detection limit

2020-02-09 Thread Matt Newville
Hi Christian,

On Thu, Feb 6, 2020, 8:40 PM Christian Wittee Lopes 
wrote:

> Dear all,
>
> Recently I was questioned about the EXAFS detection limit when describing
> different metal species in a bimetallic sample.
>
> By checking Pd and Cu K-edges, for example, I found Pd metal nanoparticles
> and CuO clusters, respectively. But additional techniques tell me I can
> have copper atoms in intimate contact with the Pd nanoparticles. What would
> be the minimum amount of these "single atoms" needed to be detected by
> EXAFS? is there a detection limit or it depends on several parameters?
>

As Chris Chantler says, there are a lot of things that can influence this,
so there really isn't one simple answer.  Also, as Chris says, advances in
analytic methods have been (mostly) been improving the situation.

At my beamline, we often get asked questions about detection limits.
 We're typically working in a different context than
nanoparticles/catalysts, but I think the basic ideas are about the same.

A good starting rule-of-thumb for absolute detection limits is 1 ppm by
atomic weight.  You might be able to do better sometimes, but there are
situations where XANES at 10 ppm is very hard.   For sure, a matrix of
light elements is much better than a matrix of heavy elements.

For very dilute samples, one will be using fluorescence XAFS measurements
with a solid-state detector or know very well why you are doing something
different.  These solid-state detectors and electronics are fundamentally
limited to have energy resolutions of ~120 eV (often 250 eV) and maximum
total count rates of 5 MHz (often 0.5 MHz).   Many beamlines use "a
handful" (2 to 16) parallel detectors, and some have up to 100 (but often
with each having a lower individual maximum count rate, and perhaps
less-than-ideal energy resolution).
With a count rate of a few MHz total and a sample with 1ppm of "element of
interest", the elastic and Compton scattering and/or fluorescence from
other elements will dominate that total count rate and the energy
resolution will give non-zero background in the fluorescence spectrum.
That means that even seeing a peak from 1 ppm of an element in an X-ray
fluorescence spectrum with a solid-state detector is challenging.  Not
impossible, but definitely not routine.

For sure, adding more detectors or counting for a long time can help.  But
those are linear in time and the number of detectors (and no beamline has
1000 parallel detectors).  Low Z matrices like water, biological material,
carbon-rich materials are easier.  Samples with nearby or overlapping
fluorescence lines are much harder.   That is 10 ppm Zn in water: yes, 1
ppm Zn in water: maybe, 10 ppm Zn in CaCO3: maybe, 100 ppm Zn in Cu metal:
no.   For sure, XANES at 1ppm is sometimes possible. Getting interpretable
XAFS would take a lot longer, perhaps days of counting.

Using filters and/or Bent Laue Analyzers in front of a solid-state (or
integrating) detector can sometimes help to eliminate the unwanted scatter
signals before they get to the solid-state detector.  Using crystal
analyzers ("wavelength" vs "energy" dispersive fluorescence) can help -
they have lower backgrounds and are not limited by the total scatter - but
the solid angle for these tend to be small.   Using crystal analyzer arrays
are probably really needed to get the best detection limits.  A few
beamlines do regularly do HERFD analysis with arrays of crystal analyzers,
and many of the rest of us are trying to catch up.  Still, I believe that
"1 ppm" is around the state of the art, if not "heroic".

All of that is for the detection limit of an atomic species.  If you are
asking about detecting Cu in/on/with Pd nanoparticles with CuO also
present, the answer is far worse.  Cu XAS measurements will be an average
of all Cu atoms in the illuminated volume -- you cannot avoid the CuO.
Seeing that 1% of the Cu atoms are bound to Pd and not to oxygen would be
very challenging.

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] XAFS.ORG WEBSITE??

2020-01-30 Thread Matt Newville
Hi All,

The millenia server for the ifeffit pages, WebAtoms, and XAFS.ORG  is now
back to being visible to the world.  Please let me know if there are any
problems.We should definitely try to track down the issue of WebAtoms
not handling data with more that 50 sites.   Matthew's CIF file should be
helpful for tracking that down.  If anyone figures it out, please let me
know!

The IXAS website is a separate disaster, but one that I am at least partly
to blame, as chair of the IXAS.   Basically the ixasportal.net domain was
held by Hiroyuki Oyanagi who sadly past away almost a year ago now.  The
domain registration was only valid through August, 2019 and the domain went
down then.  I have all of (or perhaps "most of") the web data from that
domain from the webmaster, but getting the domain itself back seems either
impossible or perhaps "very expensive".

My plan / hope is to bring up a new site using WordPress with the idea that
this will be editable by more than a couple people (but with authentication
and modern web tools).  I have the start of a site, but it is not quite
ready for beta testing.   My intention is to send this to the IXAS
Executive Committee (Hi Simon!) very soon (like, mid February) and then
announce here and other places.   I would like to move the content from
XAFS.ORG there as well -- I think this is possible.There are more
plans, including an on-line spectral database.

I will also be hoping / planning that more people (like everyone in this
thread) might be willing to participate in these efforts at least to some
extent (either editing or reviewing or making suggestions for these web
pages) once they are actually up and the Executive Committee has had a
chance to way in on this.   I'll keep you all posted, but it is completely
fair to be poking me about this on a regular basis.

--Matt



On Wed, Jan 29, 2020 at 7:48 PM Jeff terry  wrote:

> I haven’t been able to get through to the website for months. I assumed
> that they went under.
>
> Jeff
>
>
>
> Sent from my iPhone
>
> On Jan 29, 2020, at 6:58 PM, Bare, Simon R 
> wrote:
>
> Talking of websites does anyone know what happened to the International
> XAFS website? I can’t access it. And what is going on with this
> organization?
>
> Thanks.
>
>
>
> Simon
>
>
>
> ___
> 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-252-0431
___
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] what happened to the website?

2020-01-29 Thread Matt Newville
I am certain that it does not run Windows ;).  I'm also certain it will be
upgraded within a few months and that getting/testing webatoms on Centos8
is on that todo list.

Anyway, webatoms should work. I don't know why it fails with 50 sites

I hope it is back soon.

On Wed, Jan 29, 2020, 5:54 PM Matthew Marcus  wrote:

> OK, thanks.  I figured that you removed it because it's obsolete.
>
> Are you sure the server isn't running Windows 7? :-)
>
> Sincerely,
>  Matthew Marcus
>
> On 1/29/2020 3:48 PM, Matt Newville wrote:
> > Hi Matthew,
> >
> >
> > On Wed, Jan 29, 2020 at 4:39 PM Matthew Marcus  <mailto:mamar...@lbl.gov>> wrote:
> >
> > The http://millenia.cars.aps.anl.gov/ website seems to have gone
> off-line, which means that WebAtoms doesn't work anymore.  Is there a
> replacement?
> > Of course, I can use the stand-alone Atoms in Demeter.
> >
> >
> > The webpages appear to be blocked to outside (ie, outside ANL) traffic
> today.  I've put in a complaint ;).  That is, it *should* be working and
> hopefully will be back soon, but the wheels of national labs run slowly and
> only mostly forward.FWIW, "https://; is now required, but that
> *should* be automatic and is not the problem today.
> >
> > I don't have an answer for replacement.
> >
> > --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 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] what happened to the website?

2020-01-29 Thread Matt Newville
Hi Matthew,


On Wed, Jan 29, 2020 at 4:39 PM Matthew Marcus  wrote:

> The http://millenia.cars.aps.anl.gov/ website seems to have gone
> off-line, which means that WebAtoms doesn't work anymore.  Is there a
> replacement?
> Of course, I can use the stand-alone Atoms in Demeter.
>

The webpages appear to be blocked to outside (ie, outside ANL) traffic
today.  I've put in a complaint ;).  That is, it *should* be working and
hopefully will be back soon, but the wheels of national labs run slowly and
only mostly forward.FWIW, "https://; is now required, but that *should*
be automatic and is not the problem today.

I don't have an answer for replacement.

--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 Mac OS X 10.15 Catalina

2020-01-10 Thread Matt Newville
Hi Jeff,


On Thu, Jan 9, 2020 at 9:51 AM Jeff Terry  wrote:

> Hi Matt,
>
> Thanks for the help. Not your trouble. This one was thanks to Apple. I
> strongly caution anyone who is upgrading. It took out a lot of software.
> GSAS-II was a nightmare to get working again.
>
> I can confirm that the removal of pyepics allows larch to run on the
> command line.
>
> However, I now have a different problem.
>
> If I run either larch -m or sudo larch -m, I get the following error.
>
> Warning: could not create shortcut to  /Users/jterry/anaconda3/bin/larch
> Warning: could not create shortcut to  /Users/jterry/anaconda3/bin/larch
> --wxgui
> Warning: could not create shortcut to
> /Users/jterry/anaconda3/bin/xas_viewer
> Warning: could not create shortcut to
> /Users/jterry/anaconda3/bin/gse_mapviewer
> Warning: could not create shortcut to
> /Users/jterry/anaconda3/bin/gse_dtcorrect
> Warning: could not create shortcut to
> /Users/jterry/anaconda3/bin/xrfdisplay
> Warning: could not create shortcut to
> /Users/jterry/anaconda3/bin/dioptas_larch
> Warning: could not create shortcut to
> /Users/jterry/anaconda3/bin/xrd2d_viewer
> Warning: could not create shortcut to
> /Users/jterry/anaconda3/bin/xrd1d_viewer
>
> I don’t know if Apple has munged up the permissions to writing to the
> Desktop which is where the old Larch directory was placed or if something
> else has gone wrong. All the files are located in the anaconda/bin
> directory. Larch just appears unable to create the folder on the desktop or
> the shortcuts.
>
>
No, this one is entirely my fault. It really only affects the creation of
the desktop applications.   On Mac, doing

pip install pyshortcuts==1.5

and then `larch -m` should work.

I will try to get out a release of larch 0.9.47 by the end of the month
that fixes all this.
And, FWIW, the pyepics vd Py3.7.6 problem is now resolved.


Thanks,
>
> Jeff
>
>
>
> On Jan 9, 2020, at 9:36 AM, Matt Newville 
> wrote:
>
> Hi Jeff,
>
> Sorry for the trouble, and yes I can confirm this trouble.  It's actually
> not specific to MacOS version.  It appears to be related to Python 3.7.6
> (yes, 3.7.5 and 3.8.0 were OK) breaking pyepics on all systems.
> Unfortunately, a "conda update" will now install Python 3.7.6.
>
> For now, I would suggest just removing pyepics from the installation (it's
> not really necessary for Larch functionality) with
>
>rm -rf /Users/jterry/anaconda3/lib/python3.7/site-packages/epics/
>
> I think that should work, at least until pyepics gets fixed.
>
>
> On Thu, Jan 9, 2020 at 2:37 AM Jeff Terry  wrote:
>
>> Hi Matt,
>>
>> I had to upgrade my Mac to OS X 10.15 and it blew up my Anaconda
>> distribution which has forced me to reinstall everything from scratch.
>>
>> Now whether I install larch from source or by using conda, I get the
>> following error:
>>
>> Traceback (most recent call last):
>>   File "/Users/jterry/anaconda3/lib/python3.7/ctypes/__init__.py", line
>> 97, in CFUNCTYPE
>> return _c_functype_cache[(restype, argtypes, flags)]
>> KeyError: (None, (,), 1)
>>
>> During handling of the above exception, another exception occurred:
>>
>> Traceback (most recent call last):
>>   File "/Users/jterry/anaconda3/bin/larch", line 11, in 
>> load_entry_point('xraylarch==0.9.46', 'console_scripts', 'larch')()
>>   File
>> "/Users/jterry/anaconda3/lib/python3.7/site-packages/pkg_resources/__init__.py",
>> line 489, in load_entry_point
>> return get_distribution(dist).load_entry_point(group, name)
>>   File
>> "/Users/jterry/anaconda3/lib/python3.7/site-packages/pkg_resources/__init__.py",
>> line 2852, in load_entry_point
>> return ep.load()
>>   File
>> "/Users/jterry/anaconda3/lib/python3.7/site-packages/pkg_resources/__init__.py",
>> line 2443, in load
>> return self.resolve()
>>   File
>> "/Users/jterry/anaconda3/lib/python3.7/site-packages/pkg_resources/__init__.py",
>> line 2449, in resolve
>> module = __import__(self.module_name, fromlist=['__name__'], level=0)
>>   File
>> "/Users/jterry/anaconda3/lib/python3.7/site-packages/larch/__init__.py",
>> line 50, in 
>> from . import builtins
>>   File
>> "/Users/jterry/anaconda3/lib/python3.7/site-packages/larch/builtins.py",
>> line 33, in 
>> from . import epics
>>   File
>> "/Users/jterry/anaconda3/lib/python3.7/site-packages/larch/epics/__init__.py",
>> line 9, in 
>> import epics
>>   File
>> "/Users/

Re: [Ifeffit] Larch Mac OS X 10.15 Catalina

2020-01-09 Thread Matt Newville
Hi Jeff,

Sorry for the trouble, and yes I can confirm this trouble.  It's actually
not specific to MacOS version.  It appears to be related to Python 3.7.6
(yes, 3.7.5 and 3.8.0 were OK) breaking pyepics on all systems.
Unfortunately, a "conda update" will now install Python 3.7.6.

For now, I would suggest just removing pyepics from the installation (it's
not really necessary for Larch functionality) with

   rm -rf /Users/jterry/anaconda3/lib/python3.7/site-packages/epics/

I think that should work, at least until pyepics gets fixed.


On Thu, Jan 9, 2020 at 2:37 AM Jeff Terry  wrote:

> Hi Matt,
>
> I had to upgrade my Mac to OS X 10.15 and it blew up my Anaconda
> distribution which has forced me to reinstall everything from scratch.
>
> Now whether I install larch from source or by using conda, I get the
> following error:
>
> Traceback (most recent call last):
>   File "/Users/jterry/anaconda3/lib/python3.7/ctypes/__init__.py", line
> 97, in CFUNCTYPE
> return _c_functype_cache[(restype, argtypes, flags)]
> KeyError: (None, (,), 1)
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "/Users/jterry/anaconda3/bin/larch", line 11, in 
> load_entry_point('xraylarch==0.9.46', 'console_scripts', 'larch')()
>   File
> "/Users/jterry/anaconda3/lib/python3.7/site-packages/pkg_resources/__init__.py",
> line 489, in load_entry_point
> return get_distribution(dist).load_entry_point(group, name)
>   File
> "/Users/jterry/anaconda3/lib/python3.7/site-packages/pkg_resources/__init__.py",
> line 2852, in load_entry_point
> return ep.load()
>   File
> "/Users/jterry/anaconda3/lib/python3.7/site-packages/pkg_resources/__init__.py",
> line 2443, in load
> return self.resolve()
>   File
> "/Users/jterry/anaconda3/lib/python3.7/site-packages/pkg_resources/__init__.py",
> line 2449, in resolve
> module = __import__(self.module_name, fromlist=['__name__'], level=0)
>   File
> "/Users/jterry/anaconda3/lib/python3.7/site-packages/larch/__init__.py",
> line 50, in 
> from . import builtins
>   File
> "/Users/jterry/anaconda3/lib/python3.7/site-packages/larch/builtins.py",
> line 33, in 
> from . import epics
>   File
> "/Users/jterry/anaconda3/lib/python3.7/site-packages/larch/epics/__init__.py",
> line 9, in 
> import epics
>   File
> "/Users/jterry/anaconda3/lib/python3.7/site-packages/epics/__init__.py",
> line 29, in 
> from . import ca
>   File "/Users/jterry/anaconda3/lib/python3.7/site-packages/epics/ca.py",
> line 761, in 
> dbr.access_rights_handler_args)
>   File "/Users/jterry/anaconda3/lib/python3.7/site-packages/epics/dbr.py",
> line 339, in make_callback
> return ctypes.CFUNCTYPE(None, args)(func)
>   File "/Users/jterry/anaconda3/lib/python3.7/ctypes/__init__.py", line
> 99, in CFUNCTYPE
> class CFunctionType(_CFuncPtr):
> TypeError: item 1 in _argtypes_ passes a struct/union with a bitfield by
> value, which is unsupported.
>
>
>
> I think that line 11 is:  load_entry_point('xraylarch==0.9.46',
> 'console_scripts', 'larch')()
>
> Any ideas on how to address this issue?
>
> Thanks,
>
> Jeff
>
> Jeff Terry
> Professor of Physics, Illinois Institute of Technology
> ter...@iit.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-252-0431
___
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] Download Demeter in Ubuntu 18.04

2019-12-13 Thread Matt Newville
Hi Joseph, Sri,

On Fri, Dec 13, 2019 at 8:49 AM Joseph Zsombor-Pindera <
joseph.zpind...@gmail.com> wrote:

> Hi there Sri;
>
> I have had some success installing Demeter on Ubuntu. I have compiled it
> on my personal computer running Ubuntu 18.04, but unfortunately, it isn't
> plotting properly, however I was able to successfully install it on my
> colleagues computer running Ubuntu 16.04. Matt Newville is correct.
> Installing PGPlot from source would be a huge headache and wouldn't work.
> There is, however, a pgplot5 package available for Ubuntu, which you can
> install with "sudo apt-get install pgplot5". Here is the general process
> that seems to successfully compile Demeter on a clean install of Ubuntu.
> Depending on which packages you already have installed, this may change a
> little bit. I have written my explanations with # comments, so things that
> aren't commented are commands:
>
>
Please do not do this. It is not supported.  Use larch instead.

--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


  1   2   3   4   5   6   7   >