pyxem / orix-demos Goto Github PK

5.0 5.0 3.0 760 KB

Examples and tutorials of crystal orientation analysis using orix.

crystallography demo numpy orientation orix python pyxem quaternion texture tutorial

orix-demos's Introduction

pyxem is an open-source (GPL v3) python library for multi-dimensional diffraction microscopy.

The package defines objects and functions for the analysis of numerous diffraction patterns. It has been primarily developed as a platform for hybrid diffraction-microscopy based on 4D scanning diffraction microscopy data in which a 2D diffraction pattern is recorded at every position in a 2D scan of a specimen.

pyxem is an extension of the hyperspy library for multi-dimensional data analysis and defines diffraction specific Signal classes.

Installation instructions and tutorial examples are available here .

Basic Documentation is available here.

If analysis using pyxem forms a part of published work please cite the DOI at the top of this page. In addition to citing the package we would appreciate an additional citation to methods papers if you use the following capabilities:

Orientation Mapping

@article{pyxemorientationmapping2022,
    title={Free, flexible and fast: Orientation mapping using the multi-core and GPU-accelerated template matching capabilities in the python-based open source 4D-STEM analysis toolbox Pyxem},
    author={Cautaerts, Niels and Crout, Phillip and {\AA}nes, H{\aa}kon Wiik and Prestat, Eric and Jeong, Jiwon and Dehm, Gerhard and Liebscher, Christian H},
    journal={Ultramicroscopy},
    pages={113517},
    year={2022},
    publisher={Elsevier},
    doi={10.1016/j.ultramic.2022.113517}
}

Strain Mapping

Two-Dimensional Strain Mapping with Scanning Precession Electron Diffraction: An Investigation into Data Analysis Routines by Crout et al. which is freely avaliable at https://arxiv.org/abs/2307.01071

orix-demos's People

Contributors

Stargazers

Watchers

Forkers

dnjohnstone pc494 hakonanes

orix-demos's Issues

Figure out how to install dependencies for Binder

We should add a Binder badge to the readme which launches an instance installing the currently supported orix version for the notebooks... Will look into how to best set this up.

Edit: This then raises the question of which data should the notebooks use to demonstrate functionality? In my opinion, we should add a orix.data module depending on pooch, which I briefly mentioned in this issue. However, should we add more dependencies?

Replace Travis CI with GitHub Actions

We should run nbval on each PR using GitHub Actions. I can do this

orix-demos 0.3.0

Since orix-0.3.0 is released now we should have a release of the demos also.

0.5.0 RELEASE

This is a hold issue to remind me (@pc494) to run and validate the notebooks at current state so a release can be made. This will probably be 0.5.0-alpha on the assumption that the notebooks will be updated before orix is.

Archive this repository

All demo notebooks in this repository are now part of the orix user guide, and will be maintained there. I therefore suggest to archive this repository, which I will do once I get some confirmation from other maintainers (@pc494, @dnjohnstone).

~~I consider it safe to eventually delete the repository after some time, as the only reference to it that I know of is in the orix repository's README.~~

Improving the clarity and accuracy of the demos by design improvements

This issue is the result of a correspondence between the developers and @SteffenBrinckmann. Some of this discussion can be seen in #17.

A low hanging fruit (to be addressed in #18) is the placement of the small (<<100MB) data files, which will be moved into this repo, so that more of the demos run without separately accessing the google drive.

Beyond that, there are broadly, two approaches are under consideration:

Use Notebooks

Currently, we use our notebooks fairly naively, and improvements could move us a long for. For example using nbviewer (as kikuchipy does) makes the "online no download" consumption of the content much quicker. Furthermore, it seems very possible that we could test our notebooks [1] and potentially convert them to .rst files [2] with only a small investment of time.

Use doctest

This route would align our documentation more closely with hyperspy, it would probably be more readable and (being basically .rst) allow more flexible discussion (science could more easily include easy-to-render latex etc), as the "conversational" style is difficult to implement in a notebook.

General Considerations

Whatever solution is adopted, we want to be able to change the documentation in one place and one place only. This might require some clever filtering through of information. The eventual testing (travis, almost certainly) should be a cron job, to identify potential regression introduced by changing dependencies. As a philosophical position, I will say that I have always believed the notebooks to be documentation (and not an extension of our testing architecture) and I think a future decision should reflect that.

Tools

[1] - https://pypi.org/project/nbval/
[2] - https://nbconvert.readthedocs.io/en/latest/

4. Manipulating data in...

cron job for testing of the notebooks.

Hangover from #20 assinged to pc494