[Ifeffit] Larch 0.9.47

Edmund Welter edmund.welter at desy.de
Mon Mar 2 03:54:31 CST 2020


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 <mailto: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 
>> <mailto: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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://millenia.cars.aps.anl.gov/pipermail/ifeffit/attachments/20200302/7a479fa8/attachment-0001.html>
-------------- next part --------------
Traceback (most recent call last):
  File "/home/weltere/xraylarch/lib/python3.7/ctypes/__init__.py", line 97, in CFUNCTYPE
    return _c_functype_cache[(restype, argtypes, flags)]
KeyError: (None, (<class 'epics.dbr.access_rights_handler_args'>,), 1)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/weltere/xraylarch/bin/larch", line 11, in <module>
    load_entry_point('xraylarch==0.9.46', 'console_scripts', 'larch')()
  File "/home/weltere/xraylarch/lib/python3.7/site-packages/pkg_resources/__init__.py", line 489, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/home/weltere/xraylarch/lib/python3.7/site-packages/pkg_resources/__init__.py", line 2843, in load_entry_point
    return ep.load()
  File "/home/weltere/xraylarch/lib/python3.7/site-packages/pkg_resources/__init__.py", line 2434, in load
    return self.resolve()
  File "/home/weltere/xraylarch/lib/python3.7/site-packages/pkg_resources/__init__.py", line 2440, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/home/weltere/xraylarch/lib/python3.7/site-packages/larch/__init__.py", line 50, in <module>
    from . import builtins
  File "/home/weltere/xraylarch/lib/python3.7/site-packages/larch/builtins.py", line 33, in <module>
    from . import epics
  File "/home/weltere/xraylarch/lib/python3.7/site-packages/larch/epics/__init__.py", line 9, in <module>
    import epics
  File "/home/weltere/xraylarch/lib/python3.7/site-packages/epics/__init__.py", line 29, in <module>
    from . import ca
  File "/home/weltere/xraylarch/lib/python3.7/site-packages/epics/ca.py", line 643, in <module>
    dbr.access_rights_handler_args)
  File "/home/weltere/xraylarch/lib/python3.7/site-packages/epics/dbr.py", line 325, in make_callback
    return ctypes.CFUNCTYPE(None, args)(func)
  File "/home/weltere/xraylarch/lib/python3.7/ctypes/__init__.py", line 99, in CFUNCTYPE
    class CFunctionType(_CFuncPtr):
TypeError: item 1 in _argtypes_ passes a struct/union with a bitfield by value, which is unsupported.



More information about the Ifeffit mailing list