CCP1GUI Classes and Design

Classes and Inheritance

We make heavy use of the object-oriented nature of python with the intention that adapting and extending the GUI should be possible by creating new classes which can inherit much of the functionality of the existing code. A particular example of this philosophy is the successive inheritance from the classes as follows:

• Calc; a generic computational chemistry calculation. At present little data is held in this structure.
  • QMCalc; incorporating all attributes of the Calc class and including generic QM data and control structures, such as level of theory and basis set specification.
    • GAMESSUKCalc; containing the code specific to GAMESS-UK input file generation, recovery of calculation results). In future the corresponding classes for other QM codes may be implemented in the same way

    • MopacCalc; the same, for MOPAC

  • ChemShellCalc This class is not specialised for either QM or MM, since the code-specific data is held by the interfaces for the different QM and MM modules.

As similar Class heirarchy is used for the Objects responsible for the user interactions needed to set the parameters, the calculation editor objects. These functions are handled by a separate classes to help in the provision of a simple save/restore function for the calculation objects. We have chosen to use the generic Python serialisation module pickle to create file representations of the objects and it is not possible to pickle objects that contain Tkinter GUI elements.

The editor objects corresponding to the calculation objects listed above have the following names and functions:

• CalcEd; Implementation of the notebook widget used for setting up the calculation parameters, and some of the more general pages (TitlePage, a simple TaskPage, MoleculePage, ResultsPage, JobPage).
  • QMCalcEd; Currently adds a basis set selector to the Task page to the notebook.
    • GAMESSUKCalcEd; Creates all remaining pages. Information provided here includes a number of dictionaries used by the GUI to ensure that only valid choices are made available in the GUI, for example the elements of the dictionary self.theories[key] hold the list of theoretical methods available for a particular type of job, specified by key (key = "energy". "optimise internal coord." etc).

    • MopacCalcEd; the same, for MOPAC

  • ChemShellCalcEd Allows the selection of the QM and MM codes ot be used, and allows editors to be opened up to set these parameters

Another important example is the implementation of the visualisation classes. In this case the higher level classes are used to handle generic information on how to represent the resulting data (including the widgets required for user interactions) and the lower level, derived classes are concerned with the way a particular graphics or visualisation code deals with that data.

• VisualiserA base object with a dialog widget
  • MoleculeVisualiser Adds the particular interface elements needed to control the representation of a molecular structure.
    • PymolMoleculeVisualiser The code needed to render the molecule to the corresponding graphics package, in this case PyMOL

    • VtkMoleculeVisualiser Corresponding code for the Vtk back end

  • OrbitalVisualiser Adds the particular interface elements needed to control the representation of a molecular orbital.
    • PymolOrbitalVisualiserAdds PyMOL API instructions to create a surface representation of an orbital

    • VtkOrbitalVisualiser Corresponding code for the Vtk back end.

  • VibrationVisualiser Adds the particular interface elements needed to control the representation and animation of a vibrational mode
    • PymolVibrationVisualiser The code needed to render the a vibration in PyMOL.

    • VtkVibrationVisualiser Corresponding code for the Vtk back end

  ---