Using lmfit in a GUI

[Ray Osborn]

NeXpy is a PyQt application that provides a fairly simple GUI framework for analyzing mostly x-ray and neutron scattering data (https://nexpy.github.io/nexpy/), particularly but not exclusively data written as NeXus files. I have included a GUI fitting interface to lmfit for a number of years and recently updated it to include full support for lmfit models, which I don’t think had been added when I wrote the original interface. There is now a ‘Fit’ button added to every one-dimensional plot window to launch lmfit. You can see screenshots of the interface in the section on Fitting NeXus Data. I am not writing to plug NeXpy, although I would be interested in any feedback if you try it out. 

The reason for this post is to ask the developers if there would be any support for making a couple of fairly minor programmatic changes to the library. NeXpy has dropdown menus that list all the available models, which includes all the models currently defined by the lmfit package. At the moment, lmfit doesn’t provide that list in any programmatic form, so it is populated by running ‘inspect.getmembers’ to identify model classes. It would be a little less error-prone if a dictionary was added to the top of models.py containing a list of the model names and a brief one-line description. The ‘inspect.getmembers’ method works well enough so this is not a high priority.

A more serious issue is that some of the models have additional options defined by the ‘form’ keyword argument. I would like to be able to add an additional pull-down menu listing them, but as far as I can tell, there is no simple way of parsing the code to extract them. Would it be possible to add a list of valid forms to the models themselves? These would preferably be class variables so that I don’t have to instantiate every model to find them. An empty list could be added to the Model class and then overridden for each class defined in models.py.

Obviously, these changes add nothing to the functionality of lmfit as it is usually used, but I think they could help other packages that seek to incorporate the lmfit library. I don’t think there should be any side effects. If people can’t see any objection to them, I could draft a pull request.

Thanks for all the work on the lmfit package. It’s incredibly useful to us.

Ray

P.S. At the moment, NeXpy only allows models to be added to form a composite model. If anyone has ideas about how to allow models to be multiplied in a GUI, I would love to hear them.

[Matt Newville]

Hi Ray, 

On Mon, Aug 3, 2020 at 9:21 AM Ray Osborn <rayne...@gmail.com> wrote:

NeXpy is a PyQt application that provides a fairly simple GUI framework for analyzing mostly x-ray and neutron scattering data (https://nexpy.github.io/nexpy/), particularly but not exclusively data written as NeXus files. I have included a GUI fitting interface to lmfit for a number of years and recently updated it to include full support for lmfit models, which I don’t think had been added when I wrote the original interface. There is now a ‘Fit’ button added to every one-dimensional plot window to launch lmfit. You can see screenshots of the interface in the section on Fitting NeXus Data. I am not writing to plug NeXpy, although I would be interested in any feedback if you try it out. 

Great! I'll check that out.  

The reason for this post is to ask the developers if there would be any support for making a couple of fairly minor programmatic changes to the library. NeXpy has dropdown menus that list all the available models, which includes all the models currently defined by the lmfit package. At the moment, lmfit doesn’t provide that list in any programmatic form, so it is populated by running ‘inspect.getmembers’ to identify model classes. It would be a little less error-prone if a dictionary was added to the top of models.py containing a list of the model names and a brief one-line description. The ‘inspect.getmembers’ method works well enough so this is not a high priority.

Ah, good suggestion.  I have an XAS-specific and an XRF-specific GUI app that also support lmfit fitting, but they either build a list of "curated" available models (for XAS) or don't even expose the list of builtin models, using only custom built-in models (XRF).  But having a run-time way of getting that list would be good -- we should do this.

A more serious issue is that some of the models have additional options defined by the ‘form’ keyword argument. I would like to be able to add an additional pull-down menu listing them, but as far as I can tell, there is no simple way of parsing the code to extract them. Would it be possible to add a list of valid forms to the models themselves? These would preferably be class variables so that I don’t have to instantiate every model to find them. An empty list could be added to the Model class and then overridden for each class defined in models.py.

Right, that is not listed.  Maybe there should be a list of available models with data about parameter names and default and available keyword options.  I'm not 100% what that would look like, but it would be useful to me too.  In my own GUI apps, I do sort o "hardwire" these in.  It would be better for this to be discoverable.   I keep thinking that someday a general-purpose fityk-like GUI would be a good thing to do, but other things keep getting in the way. 

Obviously, these changes add nothing to the functionality of lmfit as it is usually used, but I think they could help other packages that seek to incorporate the lmfit library. I don’t think there should be any side effects. If people can’t see any objection to them, I could draft a pull request.

I agree.  Yeah, if you have an idea for how you'd like this information formatted, a PR would be welcome.

Thanks for all the work on the lmfit package. It’s incredibly useful to us.

Ray

P.S. At the moment, NeXpy only allows models to be added to form a composite model. If anyone has ideas about how to allow models to be multiplied in a GUI, I would love to hear them.

My GUIs are also all "Sum of Components"....  I guess there could be a drop-down list for the "operator" between components, but I fear that would be confusing....

Cheers,

--Matt