orix 0.6.0

[pc494]

UPDATED: New list, with a planned Mid-May release:

0.6.0

• Overwritten operator clean up; see Reconsidering the overwritten operators #139 and Dealing with division and element-wise operations on Vector3d #140
• Bugfix for Can't read some point group HDF5 datasets from EMsoft's dot product files #159 (io)
• Bugfix for Bug in EMsoft h5ebsd dot product file reader #160 (io)
• Bugfix for Stereographic plot doesn't work on unflattened collection of vectors #167
• Issue orix.sampling.get_sample_local() is quite memory intensitve #175 which is addressed in Improving SO3 sampling #193 (sampling efficiency)
• Black the whole code

Pushed to 0.7.0

• Crude colouring scheme for CrystalMap, which is talked about in both Orientation coloring framework #126 and Visualizing rotation lists in an inverse pole figure #122

Previous Text in this Issue

After conversations this week, a plan for orix 0.6.0 has solidified.

We're expecting solutions and implementation for:

• Exporting CrystalMap to ang formats (Export CrystalMap to the ANG format #127) with (.ang file format writer for CrystalMap #144)
• Documentation pages clean up, see PR Adds a documentation page into the rtfd #135
• Stereographic projection (Add stereo plot #146)

I think the main discussion here is about the final bullet point. Correct me if I am mistaken, but I think @din14970 was expecting to put a streographic projection (in a projections module?) and a (rough) IPZ plotter somewhere. Meanwhile
@hakonanes was planning RGB colouring (and a general framework for such colouring schemes).

and then this means that:

@din14970 can work on stereographic projects without any new code going in. However we probably want to drop the IPZ plotting into the framework @hakonanes is planning. Am I missing something here?

[hakonanes]

This sounds good! I'm ready to review any coming PR.

Regarding the projections module, I plan for us to put spherical, Gnomonic, and the modified Lambert projections from kikuchipy into that module. The setup is based on MTEX' spherical projection, with a projection and possibly an inverse projection. It takes vector3d or numpy arrays of arbitrary shapes with the last axis of length 3 (x, y, z). I hope we can adopt this setup (or perhaps something even better) for the projections module in orix. And reserve all plotting stuff for the plot module, since the projections won't only be used for plotting!

[hakonanes]

I can add a orix.data module with a few small example datasets, if it's desirable and if you can give me some suggestions?

For kikuchipy, I find it simpler to write documentation and test new functionality when having some example datasets available in our data module.

This would then be importable like (perhaps with a shorter name)

>>> from orix import data as orix_data
>>> xmap = orix_data.small_super_duplex_stainless_steel()
>>> xmap
Phase  Orientations                 Name  Space group  Point group  Proper point group       Color
    1  5657 (48.4%)  austenite/austenite         None          432                 432    tab:blue
    2  6043 (51.6%)      ferrite/ferrite         None          432                 432  tab:orange
Properties: iq, dp
Scan unit: um

[pc494]

I think the current consensus is to leave the orientation colouring to a 0.7.0 release & instead push on and try and release a 0.6.0 as we now have a good batch of features that have not yet shipped. I think the main things that are left are #139 and #140 (again) plus the newly noticed #175.

[hakonanes]

I think #167 should be added as well, I will have a look at this in the next couple of days.

[hakonanes]

I'm also nearly done with fixing #159 and #160.

[pc494]

Ah cool, I think mentally I had marked them as "safe to do as patch" but it would be great to have them for 0.6.0. Shall we target mid-May for a release?

[hakonanes]

Agree, they are safe to do as patches. We could add them to 0.6.1, will see how easy they are to fix. The issues you mentioned are more important!

[pc494]

Also, @hakonanes I think we should put .ipynb back in the .gitignore, if one changes the docs it's not that hard to find the -f command and it clogs up the commit list as it is because the unique IDs sometimes get changed.

[hakonanes]

Yeah, definitely, I will have a look around the internet and see if there is a simple solution.

[hakonanes]

@pc494, I can set up this release if you don't have time.

[pc494]

Update on this: the work in #193 is proving a bit more substantial than previously thought. Given that #175 isn't really fixed until that's merged I'm holding off releasing for now. I'm optimistic about the chance I can finish it in the next couple of days. But if not our release may be delayed. Anyone with strong feelings about timings, now would be a good time to shout.

[hakonanes]

The work you're doing in #193 is important, so I'm totally OK with a delay.

[pc494]

When #193 goes in I'm going to tidy up and get a release out.

[hakonanes]

Sounds good!

[hakonanes]

Released!