Unify specification of single-ion anisotropy

[kbarros]

In SU(N) mode, Sunny currently supports arbitrary anisotropy operators, and this is integrated into the symmetry analysis. See SUN_anisotropy defined here.

In dipole-only mode, Sunny currently supports quadratic_anisotropy (defined here) and to a more limited extent quartic_anisotropy (here).

Note, however, existing limitations (1) quartic anisotropies are not integrated into the symmetry analysis, (2) 6th order anisotropies are missing from dipole mode, (3) there are two distinct interfaces for the anisotropy, depending on the mode (see here).

We should unify the user-interface to specify anisotropies. That is, the same anisotropy objects should be usable regardless of mode. Specifically, I propose:

• Rename SUN_anisotropy to anisotropy_operator.
• Remove quartic_anisotropy from the user interface. Rank-4 tensors are somewhat awkward to specify directly.
• Allow the user to pass a quadratic_anisotropy matrix $J{\alpha \beta}$ to a SpinSystem with any $N$. If $N > 0$, then this will be converted to the appropriate quantum operator $J{\alpha \beta} S^\alpha S^\beta$.
• Allow the user to pass an anisotropy_operator to a SpinSystem with any $N$. If $N = 0$ (i.e. dipole-only mode) then we will convert the operator to a polynomial of spin components using the following procedure: (1) Decompose the anisotropy operator into the basis of Stevens operators, (2) Express each Stevens operator as a polynomial of spin operators (see https://www2.cpfs.mpg.de/~rotter/homepage_mcphase/manual/node132.html), (3) Replace the spin operators with expected spin components. Internally, we may wish to split apart these polynomials of scalar spin components into quadratic, quartic, and hexic parts, for consistency with the current implementation.

This refactor will make it easier for the user to switch between modes, and allows a uniform symmetry analysis regardless of mode. Also, the user will retain the freedom to specify anisotropy either as a polynomial of spin operators, or as a linear combination of Stevens operators.

This will be a breaking change. Simultaneously, I suggest we rename gen_spin_ops() to spin_operators() which is a nicer name for a function that will be exposed to users.

[kbarros]

This has been implemented for a while using polynomials of symbolic operators. In the future, we may want to switch the interface from symbolic operators to matrices.