Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fitting XRD data for thin films and superlattices #43

Closed
JET-Sci opened this issue Aug 18, 2017 · 5 comments
Closed

Fitting XRD data for thin films and superlattices #43

JET-Sci opened this issue Aug 18, 2017 · 5 comments

Comments

@JET-Sci
Copy link

JET-Sci commented Aug 18, 2017

It would be helpful if the kinematical diffraction model could be used to do a rough fit of formatted XRD data for thin films and superlattices in the same way that data for X-ray reflection can be fit. Being able to choose which factors are varied would be helpful as well.

@dkriegner
Copy link
Owner

I agree that such functionality would be helpful.

A quick fix for one particular model would be to copy the fit_xrr function for the KinematicalModel. However, in the long run this should be possible not only for the kinematical but also for the other diffraction models.

As a note to myself: This is most likely best implemented in a way that all the Models become lmfit models and somehow return a list of their parameters which can then be fitted by a generic wrapper around some lmfit minimize function. The layer stack could also be such a model which has its own parameters which can be easily combined with the ones of the model in a CompositeModel. In this way even the XRR could be fitted using this generic approach.

@dkriegner
Copy link
Owner

As a note to myself: This is most likely best implemented in a way that all the Models become lmfit models and somehow return a list of their parameters which can then be fitted by a generic wrapper around some lmfit minimize function. The layer stack could also be such a model which has its own parameters which can be easily combined with the ones of the model in a CompositeModel. In this way even the XRR could be fitted using this generic approach.

Unfortunately I was a bit naive with my comment. CompositeModel is not appropriate for this use-case since the parameters of the LayerStack are needed for the XRR/XRD models and can't be separated out.

I can imagine a solution by dynamic generation of the model function used for lmfit.Model, but this seems not a very clean solution.

dkriegner added a commit that referenced this issue Jan 18, 2019
in particular make the energy a fitable variable by recalculating the
optical parameters whenever needed
dkriegner added a commit that referenced this issue Jan 18, 2019
This in principle should fix this issue but needs a lot of testing
So far the functionality for the fitting of XRR data is equally achieved
as for the fit_xrr function which will be deprecated in the next release
@dkriegner
Copy link
Owner

The mentioned commits potentially fix this issue.
Testing and documentation updates are still needed. The issue remains open until this is fixed.

@dkriegner
Copy link
Owner

dkriegner commented Jan 21, 2019

Missing things which need some more work for XRD models to fit using the new approach are:

  • adding structural parameters (which influence the model) to the list of fit parameters
  • select appropriate fit parameters based on the model
  • rethink how to treat lattice parameter changes for Pseudomorphic stacks: I am afraid one will have to ignore this and fit only the lattice parameters of individual layers independently which might, however, not be what every user naively expects... This is more complex than I thought. I reported a separate issue Simulation of Pseudomorphic stacks (relaxation) #65
  • documentation updates: including an example script

dkriegner added a commit that referenced this issue Jan 21, 2019
This means Powder and Layer can both access this code
dkriegner added a commit that referenced this issue Jan 21, 2019
dkriegner added a commit that referenced this issue Jan 25, 2019
@dkriegner
Copy link
Owner

dkriegner commented Jan 25, 2019

I consider the main points of this issue fixed. If problems with the implementation arise or specific improvements are needed (see for example issue #65) a separate issue should be opened

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants