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,
