Plug-ins

The plug-ins are composed from three parts:

1. Parameters: the control parameters for the method implemented by the plug-in.

2. Executable core: the implementation that takes the control parameters and does the work.

3. Graphical User Interface (GUI): the implementation of the GUI that the user can use to adjust the parameters.

Each of these parts is subclassed from the appropriate base class provided by SEAMM, which ensure consistency amongst plug-ins and also minimizes the work for developers. They only need implement the parts that make their plug-in different. This structure looks like this:

UML Diagram of a Plug-in

The classes with <plug-in> in the name are the specializations of the base class supplied with SEAMM. For example, while Parameters is a perfectly useable class, <plug-in>Parameters, e.g. LAMMPSParameters is a specialization that sets up the specific parameters for the module, with their defaults, etc. when it is instantiated.

Requirements

1. Parameters must be serializable, that is the object provide a method to transform it to a text format such as json, and it must be possible to reconstruct the instance from the serialized representation.

2. Individual Parameter instances must contain meta-data defining the type or kind of values, e.g. integer, float, string or enumeration.

3. Whilst a Parameter may have a defined kind such as integer, it must be capable of storing an enumerated value or a mathematical equation instead of a specific value.

   1. An enumerated value allows e.g. a convergence criterion to be either a numerical value, or a predefined value such as ‘normal’, ‘tight’ or ‘loose’.

   2. Mathematical equations – at least basic ones – allow substitution with either a variable, e.g. ‘T’ or an expression such as ‘T + 20’ at some point in the execution of the plug-in, implicitly replacing the parameters with either a numerical value (if it is numerical, like ‘T’) or one of the enumerated values.

4. A plug-in needs, when it executes, to be able to run in its own unique environment.

5. If a plug-in executes one or more standalone executables, each executbale must have the possibility of executing in its own, separate standalone environment. Two or more plug-ins may share executables and their environments, or may require different versions and environments for the same executable.

6. Mechanisms must be provided to locate both the plug-ins and any other standalone executables that they use.

7. A mechanism and approach needs to be defined and implemented for access both the molecular system(s) needed by the plug-in, and for auxilliary information such as basis sets and forcefields. Although these might be considered as control parameters they are sufficiently large and commonly used so as to warrant special handling.

8. A mechanism for returning data from the plug-in to the entity that executed it must be defined and provided. At a minimum this should be able to handle file-based transfer of the data.