On Mon, Mar 2, 2020 at 5:27 PM Matt Newville <newville@cars.uchicago.edu> 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 <edmund.welter@desy.de> 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 <newville@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 mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit
--
--Matt Newville <newville at cars.uchicago.edu> 630-252-0431
_______________________________________________
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit