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
- MopacCalc; the same, for MOPAC
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.
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
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