Add Kikuchi lines to simulations

[dnjohnstone]

It would be nice to add Kikuchi lines to basic simulations using a simple geometric model. Perhaps starting with zone axis geometries only.

@hakonanes - don't know if you know of any packages already doing this?

[hakonanes]

Thanks for bringing this up, @dnjohnstone! I've been thinking to start looking at orix to link analysis of EBSD patterns to orientations read from vendor files, and diffsims for simulations of bands, but haven't gotten around to it...

I envision detecting bands or comparing experimental to simulated patterns with KikuchiPy, while creating indexing lookup tables (to compare the bands interplanar angles with) with orix or creating the simulated patterns with diffsims.

I haven't looked into this topic much, but I'm immediately thinking of these packages and resources which have models we could look into:

• EMsoft (Fortran):
  • I believe this is the correct place to look for detector models: https://github.com/EMsoft-org/EMsoft/blob/7762e1961508fe3e71d4702620764ceb98a78b9e/Source/EMsoftLib/detectors.f90
  • I believe the model is explained here (although the viewpoint was changed last year to looking from detector to sample): Callahan, Patrick G, De Graef, Marc: Dynamical Electron Backscatter Diffraction Patterns. Part I: Pattern Simulations, Microscopy and Microanalysis, 1255–1265, 2013, doi: https://dx.doi.org/10.1017/S1431927613001840 (Note that I at least cannot find their Part II.)
• AstroEBSD (Matlab):
  • Gnomic projection model: https://github.com/benjaminbritton/AstroEBSD/blob/master/gen/EBSP_Gnom.m
  • This model is explained here: Britton, T. B., Jiang, J., Guo, Y., Vilalta-Clemente, A., Wallis, D., Hansen, L. N., Winkelmann, A., Wilkinson, A. J.: Tutorial: Crystal orientations and EBSD - Or which way is up? , Materials Characterization 117, 113–126, 2016, doi: https://doi.org/10.1016/j.matchar.2016.04.008
  • AstroEBSD paper: Britton, Thomas Benjamin, Tong, Vivian, Hickey, Jim, Foden, Alex, Wilkinson, Angus: AstroEBSD: exploring new space in pattern indexing with methods launched from an astronomical approach, Journal of Applied Crystallography 51, International Union of Crystallography, 1–10, 2018, doi: https://doi.org/10.1107/S1600576718010373
• A lot of Aimo Winkelmann's work, e.g.:
  • Winkelmann, Aimo, Nolze, Gert, Vos, Maarten, Salvat-Pujol, Francesc, Werner, WSM: Physics-based simulation models for EBSD: advances and challenges, IOP Conference Series: Materials Science and Engineering, volume 109, 012018, 2016, doi: https://doi.org/10.1088/1757-899X/109/1/012018
  • Winkelmann, Aimo, Trager-Cowan, Carol, Sweeney, Francis, Day, Austin P, Parbrook, Peter: Many-beam dynamical simulation of electron backscatter diffraction patterns, Ultramicroscopy 107(4-5), Elsevier, 414–421, 2007, doi: https://doi.org/10.1016/j.ultramic.2006.10.006
  • His xcdskd package user guide has a tab for simulations, however so far it is empty... https://xcdskd.readthedocs.io/en/latest/simulation.html. He (@wiai) might be willing to contribute some ideas and thoughts.

[dnjohnstone]

Thanks @hakonanes for all that information - I think in the first instance I'm just thinking of a very simple geometric model to draw the lines on for experimental design in (S)TEM experiments.

I.e. the plan being for diffsims users to simulate a load of zone axes patterns to help them navigate tilting the sample around in the microscope.

If you do start making lookup tables for Kikuchi indexing - that should be diffsims functionality rather than orix. It's what diffsims already does for transmission electron diffraction.

But indeed, our longer term plan is to make diffsims depend on orix to bring that functionality through and keep anything that is crystal orientation related in orix whereas anything that is simulation based in diffsims.

[hakonanes]

OK, then, in the short term, we have different interest. What will be most fruitful for me in my work is to read EBSD master patterns, from e.g. EMsoft, and project parts of that, corresponding to a certain orientation and pattern centre, onto my detector, and then compare these simulated patterns to my experimental patterns (what EMsoft already does, i.e. dictionary indexing, but more lightweight without terminal scripting, and directly in Python). Since I start out with a finished simulated master pattern, I will implement this projection in KikuchiPy. Or can you tell if it would fit into diffsims? Since all detector parameters and the pattern centre is in my EBSD metadata already, I envision loading a master pattern, and either indexing directly via an EBSD class method (dynamic indexing in EMsoft-speak) or creating a dictionary of simulated patterns and then indexing (static indexing).

For Hough indexing, look-up tables usually mean a table of interplanar angles between pairs of crystallographic planes, i.e. not involving any simulations, only orientation computations, which I believe is orix territory?

[hakonanes]

This is in the pipeline for kikuchipy after a kikuchipy.diffraction.ReciprocalLatticePoint class is merged (see this PR pyxem/kikuchipy#197), which easily creates relevant plane families and stores relevant parameters like gspacing, band width (by supplying the acceleration voltage) etc.

Plotting plane traces, like is explained in the supplementary material for the paper Britton et al. (referenced above, https://doi.org/10.1016/j.matchar.2016.04.008), then includes a series of transformations from the unit cell to the detector. I have this more or less figured out for an EBSD detector based on that work, but haven't got a robust implementation yet.

[dnjohnstone]

This is in the pipeline for kikuchipy after a kikuchipy.diffraction.ReciprocalLatticePoint class is merged (see this PR pyxem/kikuchipy#197), which easily creates relevant plane families and stores relevant parameters like gspacing, band width (by supplying the acceleration voltage) etc.

Plotting plane traces, like is explained in the supplementary material for the paper Britton et al. (referenced above, https://doi.org/10.1016/j.matchar.2016.04.008), then includes a series of transformations from the unit cell to the detector. I have this more or less figured out for an EBSD detector based on that work, but haven't got a robust implementation yet.

Should this all just go directly into diffsims?

[hakonanes]

Did you take a look at the example in the top PR comment (pyxem/kikuchipy#197)?

There is definitely overlap between the ReciprocalLatticePoint (rlp) class and the stuff in https://github.com/pyxem/diffsims/blob/master/diffsims/utils/sim_utils.py. I've looked into those functions, and I think it would be easier to use and extend that functionality by using a class like rlp.

I would be interested to hear from anyone working on something for diffsims at the moment, if they would be interested?

I thought of creating a kikuchipy.detectors module to handle EBSD projection (pattern) centre stuff, which I think doesn't fit into diffsims.

[dnjohnstone]

Yep - I think everything in pyxem/kikuchipy#197 would be a better fit in diffsims in terms of where I see the modularity of packages. The kikuchipy.detectors does sound different though.

Is there any issue with doing that?

It would actually solve a number of issues highlighted in #104

Also, you'd get things like alternative parameterizations of electron scattering factors that we already have in diffsims, which I think are good alternatives to the ones you've used.

[pc494]

I'm (softly) pro pyxem/kikuchipy#197 going into diffsims, as that seems to preserve the hyperspy/non-hyperspy distinction we have with pyxem at the moment.

[hakonanes]

Yep - I think everything in pyxem/kikuchipy#197 would be a better fit in diffsims in terms of where I see the modularity of packages. The kikuchipy.detectors does sound different though.

Yeah, the detectors module is a little ways off yet, we can discuss that at a later stage.

Is there any issue with doing that?

It depends on what functionality it will replace. I can set up a WIP PR with a suggestion of its place in the package structure, and then we can work out what stuff to change together.

It would actually solve a number of issues highlighted in #104

Sorry, it's not clear to me which issues in that PR this would address? Could you give some specifics?

Also, you'd get things like alternative parameterizations of electron scattering factors that we already have in diffsims, which I think are good alternatives to the ones you've used.

If you mean giving the user the option to pick from all these parametrizations, including the Doyle-Turner I've included in that PR from EMsoft, then that sounds great.

---

It is just a good idea in general for me to put that stuff into diffsims, since it will be used more and errors will be discovered quicker.

[hakonanes]

I'm (softly) pro pyxem/kikuchipy#197 going into diffsims, as that seems to preserve the hyperspy/non-hyperspy distinction we have with pyxem at the moment.

No HyperSpy, only orix, diffpy.structure and numpy.

[pc494]

I'm (softly) pro pyxem/kikuchipy#197 going into diffsims, as that seems to preserve the hyperspy/non-hyperspy distinction we have with pyxem at the moment.

No HyperSpy, only orix, diffpy.structure and numpy.

Sorry, this wasn't clear from me at all. diffsims is hyperspy free, and so one (naive) way of deciding if code should be in diffsims or pyxem is "does it depend on hyperpsy", if the answer is no, it's often because it's diffsims-like code.

[hakonanes]

Makes perfect sense to me, I like the simple guide.

[dnjohnstone]

It depends on what functionality it will replace. I can set up a WIP PR with a suggestion of its place in the package structure, and then we can work out what stuff to change together.

It would replace a number of things in the current diffsims like the functions get_kinematical_intensities, get_unique_families and some others.

It would actually solve a number of issues highlighted in #104

Sorry, it's not clear to me which issues in that PR this would address? Could you give some specifics?

Well in #104 one aim was to harmonize powder pattern simulations with single crystal diffraction pattern simulations. I think basing both of those off of the ReciprocalLatticePoint class would be a much better architecture. Also some current functions, particularly get_unique_familes are simply not correct in diffsims right now because we didn't really use the powder pattern simulator until now. The specific issue is that it is a bit of code that doesn't work for non-cubic systems and I think your approach to finding multiplicities is actually correct in general.

Also, you'd get things like alternative parameterizations of electron scattering factors that we already have in diffsims, which I think are good alternatives to the ones you've used.

If you mean giving the user the option to pick from all these parametrizations, including the Doyle-Turner I've included in that PR from EMsoft, then that sounds great.

Yes, that's what I mean. The current diffsims utilities of get_scattering_parameters_dict and get_vectorized_atomic_scattering_factors do this job for us at present where we select between the electron scattering factors in the International Tables and the more modern Lobato ones. Doyle-Turner is fine, but they're pretty dated.

It is just a good idea in general for me to put that stuff into diffsims, since it will be used more and errors will be discovered quicker.

I think basically your ReciprocalLatticePoint class is a very good idea and may well be how we would start with both our powder pattern simulator and our single crystal simulator if we were starting diffsims now. Since you've done it, I think it would make much stronger foundations for everything to have this all in one place.

Also the points from @pc494 about being "hyperspy independent" is a good thing for use and re-usability I think.