[Ifeffit] Larch 0.9.47

Garret Bland gbland at andrew.cmu.edu
Tue Mar 3 08:00:42 CST 2020


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 <newville at 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 at 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 at 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 at 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://millenia.cars.aps.anl.gov/pipermail/ifeffit/attachments/20200303/dec34822/attachment-0001.html>


More information about the Ifeffit mailing list