adding an `orix.crystal` module

[argerlt]

I was looking at finishing #563 (replacing quaternion.symmetry.Symmetry with quaternion.symmetry.PointGroup) and started to think about this conversation from last year (paraphrased slightly):

... but to maybe put a finer point to [the] suggestion. My problem is the names of the modules.

...from orix.crystal_map import Phase confused me for a for a long while. And looking through the modules now I don't really have the first guess as to where the symmetries and point groups would be imported.

Quaternion -> transform
Crystal_map-> ???

Originally posted by @CSSFrancis in #573

My problem is the names of the modules.

I agree with you, but I don't think it's worth it to move classes. I suggest to keep it as-is just because current users are used to it.

The module names are historical. When we introduced the crystal map, we first thought of that, and then that we needed a class for crystallographic phases (symmetry + unit cell). The class was placed in the crystal map module since it was to be used there. Then, of course, it became required for crystal directions (the Miller class), and suddenly it doesn't make much sense for the phase class to be in the crystal map module.

looking through the modules now I don't really have the first guess as to where the symmetries and point groups would be imported

The symmetry class was placed in the quaternion module because it subclasses the quaternion class. I would not do it like that if I were to write the class again, but it's not worth it to change that fact, I think.

Originally posted by @hakonanes in #573

Before I spend a bunch of time making a new class in quaternion.symmetry, what are people's thoughts on adding an orix.xtal module that contains Phase, PhaseList, Symmetry, and PointGroup? IE, take all the scattered class functions from across orix that deal with symmetry and crystallogrphy and put them in one spot?

This, to me, would be the most logical rearrangement, and we could leave behind warning functions for a few versions that reference the Class's new locations. Since they are major functionality change as well, we could even copy what @ericpre did in rsciio and leave the warnings in until orix 1.0.0.

[hakonanes]

I think it's a good idea to introduce a new module, and I agree with those four classes being moved there. I also agree with the deprecation plan, to leave the shell of the old modules behind and emit a warning to use the new paths instead.

I vote for calling the module orix.crystal. This is in line with other module names being written out completely (quaternion and not quat, vector and not vec).

Also, it's important to think about interdependency of modules. Arguably, we haven't given this much thought in development so far. But we should going forward, because strong coupling and mixing of separation of concerns are difficult to work as developers. The new crystal module would depend on both the vector and quaternion modules. In return, those modules would depend on the crystal module for rotation and direction symmetry. We should be smart about the file structure to minimize the effect of this coupling.

[argerlt]

I vote for calling the module orix.crystal
agreed.

Also, it's important to think about interdependency of modules. .... e should be smart about the file structure to minimize the effect of this coupling.

This is the layout I am suggesting (ignoring unchanged modules that depend on a combination of these 3):

.
├── base.py
    └── Object3d
├── crystal
    ├── Phase.py
    |       ├── Phase
    |       └── PhaseList
    └── PointGroup.py
          └── PointGroup
├── quaternion
    ├── Quaternion.py
    |       └── Quaternion
    ├── Rotation.py
    |       └── Rotation
    ├── Misorientation.py
    |       └── Misorientation
    └── Orientation.py
             └── Orientation
├── vector
   ├── Vector3d.py
   |       └── Vector3d
   └── Miller.py
           └── Miller

The only oddity I see is quaternion.Orientation depending on crystal.PointGroup, which is then dependent on quaternion.Quaternion. Thinking ahead a bit, I think there is a strong argument for the following:

.
├── base.py
    ├── Object3d
    └── Quaternion
├── crystal
    ├── Phase.py
    |       ├── Phase
    |       └── PhaseList
    └── PointGroup.py
          └── PointGroup
├── transform
    ├── Rotation.py
    |       └── Rotation
    ├── Misorientation.py
    |       └── Misorientation
    └── Orientation.py
             └── Orientation
├── vector
   ├── Vector3d.py
   |       └── Vector3d
   └── Miller.py
           └── Miller

So quaternion is a "base" class below the newly renamed "transforms" module (I think @CSSFrancis made that suggestion, and I do like it, especially when the base quaternion is not part of the transforms package), and all inheritance is top-down:

• base is the starting point
• crystal builds from base
• vector and transform build from base and crystal
• everything else (projection, data, plot, crystalmap, etc) builds from vector and transform.

Which has a few other benefits:

1. the quaternion vs numpy base problem is detangled from the transform module.
2. cleaner modularity
3. if some day we decide ORIX is too big/convoluted, it makes it a lot easier to separate the core conventions (transform, crystal, and vector) from the plotting/data handling modules.

THAT SAID, I think doing this all at once is too much, and I can just start with a crystal module, as it's a step in this sort of direction.

Thoughts?

ADDENDUM: It looks like OrientationRegion depends on Rotation and Symmetry, which upsets this neat vision a bit, but it could be detangled.