Initial proposal for an Octopus GUI

From OctopusWiki
Jump to: navigation, search

This is a project for a GUI for octopus

Main

These are my ideas for the GUI of octopus. This is a bit different from most other GUIs for scientific programs I have seen, and I guess that the final product will be quite different from these ideas. In any case, they will serve as a starting point for further discussions.

There are some details that should be taken into account when building the GUI:

  • The number of input variables in octopus is growing at a rapid pace, and we do not want to change the GUI when we add/change a variable to the code.
  • I don't think that we can create a “bulletproof” GUI. However, we should try to build a simple interface, that can be used by a university student for his classes of quantum mechanics/solid-state physics.
  • The GUI should also be useful for us, in, for example, visualizing our results. Also we should not reinvent the wheel in what comes to visualization. For example, we should make use of the openDX libraries to make 3D plots.
  • Octopus runs in 1, 2, or 3D. This will have to be reflect some how in the GUI. Maybe we can think about this later, and just assume, at this point that we are in 3D. The same goes to infinite systems. These latter will imply that we define the lattice (maybe as a part of the geometry).

I will not handle the time-dependent runs. As the visualization part of these runs is a bit harder, I believe that we should taken care later of them on.

Project

The GUI for octopus is going to be built around the concept of a “project”. The main constituent of a project is a starting geometry. Let me give an example:

  • project CO
    • geometries
      • __CO.xyz__
    • species
      • C
        • input
        • output
        • __C.ascii__
      • O
        • input
        • etc.
    • ground state
      • input
      • output
      • wave functions
      • density
    • optical spectrum

Note that I put a couple of entries in bold. These are defaults. Let me explain it a bit better. We may want to have more than one geometry stored in the project, and more than one pseudopotential for carbon. I am still not sure if this is necessary/useful, so please give me your opinion. Also I don't know if we should allow for more than one geometry. Maybe not.

The structure of the project will obviously be mirrored by a directory structure. A project in disk is nothing more than a directory, containing input/output files and possibly some files containing meta data. So, in this case, there would be a directory called CO

  • CO
    • config
    • defaults
    • geometries
      • CO.xyz
    • pseudos
    • etc.

The config file will contain some information, like the name of the project, while the default file will detail which are the default pseudos and geometry. (Note that you should be able to open the project without the presence of these 2 files.) The actions that one may perform will depend on the file type. I will describe this in more detail in the following.

Note that there are some entries in the project that are created by/from the GUI (like the inputs), while others are created by octopus (or by the pseudopotential program). This means that the GUI will have to scan the directory structure to find out what is in the project.

GUI1.png

Schematically, I think the GUI should look like the image above. Area (1) should include the menu and a toolbar; (2) should contain a tree view of the project, and finally (3) is a general purpose panel, where most of the work will take place. The menu will contain the following

  • File
    • New
    • Open
    • Close
    • Print (prints the panel (3))
    • Quit
  • Project
    • Add
      • Geometry
      • Pseudopotential
      • Run
      • Text File
  • Actions
    • Edit input (active when an input is selected in the project)
    • Run octopus (active when a run mode is selected)
    • Delete
    • Center geometry (active when a geometry is selected)
  • Help

When one creates a new project, one will be prompted with a dialog box asking for: Directory where to store the project, Project name, Initial geometry, Comments. From these, only the directory has to be filled. The GUI will then create the stipulated directory. The next step of the user will be to make a new Run. From the menu Project->Add->Run, he will be greeted with a dialog box with the possible run modes he will be able to perform (like ground state, unoccupied states, or optical spectrum). This will add a new run mode to the project (a new directory), link the default geometry and default pseudopotentials to that directory, and create a prototype input file. This will also put the GUI in “input mode”.

There will several different modes in the GUI, input mode, visualization mode, run mode, pseudopotential mode, etc.. The first is when one builds the input file for octopus, the second when one visualizes the output, the 3rd when one runs octopus, and the species mode when one creates/changes a species/pseudopotential. The first three interface with octopus, will the last will interface with the pseudopotential code.

Input Mode

One enters input mode when selecting an input file on the project, or by choosing Run->Modify input. This will open in panel (3) the input panel. The objective of this mode is to generate the input file that will then be used to run octopus. As the variables of octopus increase and change too rapidly, they should not be hard-wired in the GUI. Instead, the GUI should read the files share/varinfo from octopus, in order to retrieve all necessary information. This information will likely have to be increased. Let me use an example (from a slightly changed file varinfo)

<verbatim> Variable Hamiltonian::Exchange-correlation::SICorrection Type integer Description

This  variable controls which Self Interaction Correction to use.
Note that this  correction  will be applied to the functional
chosen by 'Xfunctional' and 'CFunctional'

Option sic_none 1

No Self Interaction Correction

Option sic_pz 2

SIC a Perdew Zunger, handled by the OEP technique

Option sic_amaldi 3

Amaldi correction term (NOT WORKING)

Default sic_none ~RunModes all Level Intermediate END </verbatim>

Let me describe a bit the fields:

  • Variable: is the Section<::Sub Section>::Name of the Variable. This allows for a logical structuring of the variables.
  • Type: is the type of the variable. Can be integer, real, complex, string, or block. Note that, if the type is integer, there may be some predefined options.
  • Description: some text describing the variable. Note that a line starting with a space is a continuation line.
  • Option: the syntax is <Name of the option> <integer value>. It is used for variables where we can choose between different options. Only exists for integer variables.
  • Default: the default value for the variables.
  • ~RunModes: In which run modes can this variable be used. Can have the values all, gs, td, unocc, etc. (more will decided later).
  • Level: Can have the values Basic, Intermediate, and Expert (default).

GUI2.png

So, in the initialization of the GUI, the file varinfo should be read, and its information parsed, and stored in memory. The input panel should present this information as shown in the right. (a) is a drop box that allows the selection of the Level. (b) is another drop box that allows to select variables specific to the run mode, variables that can be used in the run mode, and all variables.

The edition of the value of the variable will of course have to take into account its type. Special care will have to be taken with blocks. The information should be saved in a file called “inp” in the directory of the run. However, only the values that are different form the default value should be saved. This allows for shorter, human readable files. Furthermore, the variables should be sorted by section, and then alphabetically. Of course, we (octopus developers) will have to make a big effort at the beginning to document conveniently the input variables in the code.

Now that we have an input, we can run octopus, i.e., enter the run mode.

Run Mode

We enter in this mode by either choosing Run octopus from the menu, or by clicking on a button. Basically, this runs octopus, while showing the output on panel (3). When octopus finishes the run, the GUI should analyze if the run was successful, if the calculation converged, etc., and should inform the user with some dialog box. The GUI should also be attentive to the input errors (if any) and help the user to handle them. Furthermore, as octopus will have created some output files, the GUI will have to reread the directory in order to update the project window.

Species Mode

In this mode, the GUI should allow the user to input a user defined species, or created a pseudopotential with the pseudopotential code. The interface to the latter should be essentially the same as the web interface in http://tddft.org/programs/octopus/pseudo.php When on chooses Project->Add->Pseudopotential, one is greeted with a periodic table allowing to choose the element, and an input box to select the name of the subdirectory where it will be created.

Visualization Mode

This mode will depend on the type of file selected in the project.

DX file

(Like the density or the ELF.) This should open a window where the 3D representation of the function is shown. Basically, this should replicate the functionalities of the openDX application we already developed. In order to facilitate the development of this part, I believe that it would be best to use the openDX libraries to do the work. I haven't used them myself, but a quick search made me believe that this is possible. Of course the user should be able to rotate, magnify, make isosurfaces, etc. The user should also be able to save images (screenshots of panel (3)) and to print them.

XYZ file

(Geometry file.) This should show the geometry in panel (3). Again, this should use the OpenDX libraries, and have the functionality of our openDX application.


Wavefunctions

GUI3.png

This is not a single output file, but normally a collection of DX files, which, together with the info or eigenvalues file contains all information regarding the eigen-energies and eigen-functions. The GUI should start by parsing the info or (if it exists) the eigenvalue file, and show the information graphically as shown in the diagram. The lines correspond to the different eigen-energies for each spin channels and/or k-point (their values should appear below when the mouse passes over). Then, if the user clicks on a level and if the wave-function is available, then it should be plotted on the panel.

Text

(Output files, etc.) Should just appear in panel (3).