Re: [Ifeffit] Larch user base?

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 wrote:

Hi Sean,

On Sun, Aug 14, 2016 at 4:35 PM, Sean Fackler javascript:_e(%7B%7D,'cvml','swfackler@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