Re: [Ifeffit] Larch 0.9.47

[George Sterbinsky]

Hi Matt,

Thanks, that worked. I got an error that said something about 'asteval' on
my first try, so I also deleted that package.

George

On Sat, Apr 18, 2020 at 11:24 AM Matt Newville 
wrote:

> 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
>
___
Ifeffit mailing list
Ifeffit@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

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

[George Sterbinsky]

Hi All,

I am trying to upgrade larch from 0.9.45. Neither "conda update --all" nor
"pip install xraylarch" are updating to 0.9.47. Is a complete reinstall of
anaconda my only option?

Thank you,
George

On Tue, Mar 3, 2020 at 11:22 AM Matt Newville 
wrote:

> 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
>
___
Ifeffit mailing list
Ifeffit@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

[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

[Garret Bland]

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

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

On Mon, Mar 2, 2020 at 5:27 PM Matt Newville 
wrote:

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

Re: [Ifeffit] Larch 0.9.47

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

Re: [Ifeffit] Larch 0.9.47

[Edmund Welter]

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 
mailto:newvi...@cars.uchicago.edu>>:


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



___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov

Re: [Ifeffit] Larch 0.9.47

[Mangold, Stefan (IPS)]

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 
mailto:newvi...@cars.uchicago.edu>>:

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

___
Ifeffit mailing list
Ifeffit@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.47

[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