[Ifeffit] Larch user base?

Sean Fackler swfackler at lbl.gov
Mon Aug 15 12:23:30 CDT 2016


Thanks Matt for the thorough explanation.

Actually it was Jamie Sethian who asked. I am working on using Larch as a
code basis for doing high-throughput NEXAFS analysis. You can imagine
automating just basic normalizing and background subtraction steps would be
invaluable in this case. I am working with CAMERA ( Alex Hexamer, Ronald
Pandolfi ) on making a GUI and Materials Project ( Patrick Huck ) along
with ALS ( Alpha N'Daiye ) to have some sort of database contribution
route. Data is coming from ALS beam line 6.3.1.

I will be calling on you as I learn Python concurrently with implementing
Larch. For example, I got read_ascii to work but couldn't get the plot
functions to work and get "newplot not defined." I am using 2.7 on Mac OSX
El Capitan. Any ideas?

Thank you!

Sean

On Sunday, August 14, 2016, Matt Newville <newville at cars.uchicago.edu>
wrote:

> Hi Sean,
>
> On Sun, Aug 14, 2016 at 4:35 PM, Sean Fackler <swfackler at lbl.gov
> <javascript:_e(%7B%7D,'cvml','swfackler at lbl.gov');>> wrote:
>
>> Hello all!
>>
>> Do you have an idea of Larch user base or Larch package download stats?
>> Thanks for any information.
>>
>>
> Funny you should ask.   It turns out that a kind and generous NSF Program
> Manager recently gave me a friendly reminder that I promised to include
> such information in a report to them.   I think I haven't been doing enough
> to promote or discuss development of Larch, so while we're at it, I should
> probably give an update on the status of Larch and where it looks to be
> going over the next couple years.
>
> First, your question:
>
> The recommended way to download / install Larch in now via Anaconda.org:
> https://anaconda.org/newville/xraylarch, which conveniently keeps
> statistics. This reports more than 180 downloads in 2016.  That's low
> compared to Athena/Artemis, but not terrible.  Many of these are probably
> from users of my beamline, where Larch includes the Visualization tools for
> the XRF maps we make, but then again, this was a major motivation for Larch.
>
> For another metric, I counted about 1 discussion per month on this list
> about Larch.   There are at least that many discussions where Bruce or I
> eventually say "what you're asking would be much easier with Larch".
> While low compared to questions about using Demeter many of the Demeter
> questions posed don't really discuss the underlying analysis engine.
>
> Anecdotally, I've had many discussions over the past year about Larch,
> including getting "advanced" Athena/Artemis users and beamline scientists
> to use it.   The conversations always seem positive to me, but I don't know
> that many people have really taken it up from these discussions. I've also
> had several discussions with people (beamline scientists or visiting
> scientists) at the APS in a similar manner -- many seem interested, but I'm
> not sure the adoption rate is very high.  There are definitely a handful of
> folks trying to use it from Python.
>
> Athena and Artemis can already use Larch, and I think both Bruce and I are
> expecting that Larch will be expected to be the default over the next
> year.
>
> Larch status and near-term directions:
>
> I'm about to merge a large set of changes (https://github.com/xraypy/xra
> ylarch/pull/139) and push a new release of Larch (0.9.30), probably later
> this week.  The main changes / updates for this release are:
>     1. initial support for Python 3.  All the basic stuff is working, but
> there may still be some small problems with unicode vs. strings, and with
> the wxPython GUIs
>     2. support for wxPhoenix, the not-yet-officially-released version of
> wxPython that will support Python 3. Again, there may be a few problems
> still to uncover, but stuff is mostly working for me with wxPhoenix on
> wxPython.
>     3. improvements and simplifications to the internal "read-eval-print"
> loop code (some of the oldest code in larch) and to the presentation of
> exceptions / error messages.
>     4. A reader for Athena project files to Larch groups.  A writer will
> soon follow, I expect.
>
> As mentioned, we have funding and have hired a scientist to work on parts
> of Larch.  This is to integrate and/or improve 4 aspects:
>    1. handling micro-XRD data, and automating phase ID from micro-XRD maps.
>    2. better fitting / quantitative XRF analysis.
>    3. better XANES fitting and linear analysis methods (PCA, and more).
>    4. improved EXAFS analysis, incorporating dedicated Feff85EXAFS.
>
> We think we know how to do all of these steps, but we'd love help with any
> part of this.   The person we've hired is tackling #1 first,  For my part,
> I'll be working on #3, and a dedicated GUI for XANES analysis over the next
> several months.
>
> There are several related projects (mostly python), including
> https://github.com/xraypy/feff85exafs, https://github.com/scikit-beam/,
> https://github.com/lmfit/lmfit-py.   LMFIT grew out of Larch, but has
> grown substantially from outside collaborators. I expect that part of the
> XANES and XRF fitting work will migrate Larch's fitting to just depend on
> LMFIT.   It's possible that some of the domain-specific libraries for
> analysis (Xray databases, for example at https://github.com/scikit-
> beam/XrayDB) will migrate to scikit-beam, with Larch then depending on
> that.
>
> Larch is definitely ready to be used.  Many aspects are still in
> development, but the core EXAFS analysis is working.  If you or anyone is
> interested in trying it or working with the code, don't hesitate to give it
> a try.
>
> Sorry for such a long answer to a short question!
>
> --Matt
>
>
>
>

-- 
Sean Fackler, PhD
Joint Center for Artificial Photosynthesis
Lawrence Berkeley National Lab
1 Cyclotron Rd, Mail Stop 30R0205
Berkeley CA, 94720
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://millenia.cars.aps.anl.gov/pipermail/ifeffit/attachments/20160815/b8897765/attachment.html>


More information about the Ifeffit mailing list