#121 Bundle states and representations

[Ulf Lorenz]

In many contexts, you have to supply a state and the representation it is tied to, for example the various RepresentationUtilities functions (e.g., normalization). This is a must because these functions hide the differences between wavefunctions and density operators, so they need to know what they are getting.

Originally, I did not want to bundle states with their representations, because it may be slow, and because it makes non-standard manipulations more cumbersome (when playing around with multiple similar representations, for example). However, I am not sure about the performance penalty, and I find myself even in testing situations not doing the advanced manipulations I was originally thinking about. So probably the convenience trumps here.

Also, when the state and representation are combined in some structure, we have a natural place to combine some further functionality, for example: is the state valid? Do we have a density operator or wavefunction? etc.

In any case, before starting this issue, benchmark the performance penalty with a test setup!

Other functionality that would be well-placed with such a state structure:

• hide the CTensor if we want that (external library, exposing of detailed internal data even if the user does not want it)
• simpler setup of vectors of states
• create an OperatorPrimitive from a density matrix
• create the adjoint density for a given (non-Hermitian) state
• the state could also hold information about which representation (DVR, FBR, weighted DVR) we are currently in. This in turn can be used by actions to reject pointless operations (such as a DvrToFbr transformation on an FBR state)

---

• slowdown for Chebychev solvers up to 15% for small 1D systems; negligible (~3%) for larger systems (2D)
• similar speed_up_ due to optimization for ODE solvers
• modernized Interferometry demo along the way; looks much neater now.
• removed MolVibration/OH3 from build, since the demo does not work properly anyway.