each reflection should be handled as a Python class

[prjemian]

If all the details of each reflection were handled as a Python class, then many open issues would become much easier to resolve.

Thanks @strempfer for the motivation of this issue!

---

• [ ] #219
• [x] #215
• [ ] #178
• [ ] #176
• [ ] #161
• [ ] #158
• [ ] #157
• [x] #154
• [x] #143
• [ ] #10
• [ ] https://github.com/APS-4ID-POLAR/ipython-polar/issues/146
• [ ] names of positioners, both pseudos and reals

[prjemian]

Such as #143

[prjemian]

A reflection should be pre-configured with the names of the positioners it uses, both pseudos and reals.

[prjemian]

Notes

A reflection represents a specific coordination between:

• a set of diffractometer angles in real-space (known here as reals), used by a specific diffractometer geometry
• a set of crystalline coordinates in reciprocal-space (known here as pseudos), used by a specific computational engine
• an incident wavelength

The names and ordering of the reals are specified by the diffractometer. The names and ordering of the pseudos are specified by the reciprocal-space computational engine.

A diffractometer may have several samples, each with their own list of reflections. The reciprocal-space computational engine cannot be changed once the diffractometer object is created.

Refactor, considering:

• Each HklSample object has its own set of reflections.
• A HklSample object (created in hkl.calc) needs to know the Diffractometer object to which it belongs.
  • Users call the HklSample.add_reflection() method for new reflections
  • The CalcRecip needs the diffractometer object to which it belongs to create the HklSample

[prjemian]

Note that:

• real axes might be renamed by the user
• additional real axes might be defined which are not used in real:reciprocal space transformations
• additional virtual axes might be defined which are combinations of other real-space axes

[prjemian]

The DCReflection class (in #280) will enable this.