There are two usability issues with electronic states / coupled channels.
For the user, they are annoying to use. The coupled channel itself is reasonably easy to set up, but setting up operators projected onto a state or coupling states is plain annoying. There has to be an easier way to do that.
Suggestion here: When setting up a coupled channel, offer to give the channels names, and allow the user to refer to these names in a simple way. Or use channel indices everywhere.
For developing, coupled channels are annoying because many observers do something per coupled channel, like plotting or calculating expectation values. Effectively what happens then is that they loop over all coupled channels and try to do something with a reduced grid without the coupled channel. No good idea here.
Optionally, we could also consider having multiple coupled channels degrees of freedom (say, electronic states and ghost states for density coupling schemes) over which to iterate. But this is an advanced topic with uncertain use that could be put into a followup issue.
Do we really want to do that?
Several observers have pretty complex logic to handle electronic states or do not work with them. This is kind of annoying: When you, for example, log output or plot a wave function distributed over different electronic states, you will log/plot the wave function for each electronic state separately. That is, you kind of handle the wave function as if you had a bunch of wave functions of reduced dimensionality.
This suggests that there should be some general way of dealing with electronic states in analogy to having states made up of multiple wave functions.
Along the way, the Plot1DObserver currently has an assertion that makes one of the tests fail in debug mode.
Suggestion
One idea would be to have four components:
This leaves open the question how to deal with density operators. it is also just an idea, not the solution.
Diff:
Diff:
Related
Tickets:
#154Diff:
Related
Tickets:
#154Diff:
Diff: