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: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 mailto:Ifeffit@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

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, `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 listIfeffit@millenia.cars.aps.anl.govhttp://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

-- Garret Bland PhD Student Carnegie Mellon University Civil and Environmental Engineering Porter Hall 201 Pittsburgh, PA, 15213

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

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