Menu

#108 Easier handling of electronic states

0.5 goal
open
nobody
None
nobody
2024-04-01
2017-09-28
Ulf Lorenz
No
What and Why

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.

old

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:

  • a different representation similar to the original one but without the electronic state
  • observers (e.g., loggers) that would work on this different representation
  • another observer that works on the original representation. It transforms each electronic state into the other representation and runs e.g. the logger on the set of transformed wave functions.
  • a factory function or so that sets up everything conveniently and easily

This leaves open the question how to deal with density operators. it is also just an idea, not the solution.

Related

Tickets: #110

Discussion

  • Ulf Lorenz

    Ulf Lorenz - 2019-03-21
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,6 +1,8 @@
     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_
    
     
  • Ulf Lorenz

    Ulf Lorenz - 2019-04-25
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -14,3 +14,5 @@
     * a factory function or so that sets up everything conveniently and easily
    
     This leaves open the question how to deal with density operators. it is also just an idea, not the solution.
    +
    +Note: related to [#154]
    
     

    Related

    Tickets: #154

  • Ulf Lorenz

    Ulf Lorenz - 2020-01-01
    • Milestone: Backlog --> 0.4 goal
     
  • Ulf Lorenz

    Ulf Lorenz - 2020-05-21
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,3 +1,17 @@
    +#####What and Why#####
    +
    +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.
    +
    +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.
    +
    +#####old#####
    +
    +** 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.
    @@ -14,5 +28,3 @@
     * a factory function or so that sets up everything conveniently and easily
    
     This leaves open the question how to deal with density operators. it is also just an idea, not the solution.
    -
    -Note: related to [#154]
    
     

    Related

    Tickets: #154

  • Ulf Lorenz

    Ulf Lorenz - 2020-05-21
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -7,6 +7,8 @@
     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.
    
     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.
    
     #####old#####
    
     
  • Ulf Lorenz

    Ulf Lorenz - 2020-11-08
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -4,7 +4,7 @@
    
     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.
    +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.
    
     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.