5.3.4 Configuration

Supporting a run-time configuration allows to define and drive the execution of the framework without the need for recompilation. As already indicated, ViennaX utilizes an input file - potentially provided by advanced users - approach based on XML, which’s path is provided to the application via a command-line argument. Such a file-based method also enables possible future pairing with a GUI application generating configuration files upon an end user’s behest in a straightforward manner, therefore eliminating the need for users to generate the configuration files by hand, further improving the support for end users. This input file contains information regarding the components to be utilized for the execution and also parameters for each component. In a first step the framework processes this input configuration and extracts the list of components to be utilized for the execution. According to this list, the corresponding components are created. In a second step, the component-specific parameters are extracted and forwarded to each individual component, allowing the component to change the setup of its input and output dependencies accordingly. In the following step, the execution order is determined by the schedulers, as the input and output dependencies are - at this point - final.

Using an XML approach for the input configuration data offers similar advantages as the previously discussed material database approach introduced in the context of the device simulation framework (Section 4.3.2). Most essential is the support for an arbitrary number of components, by using a dedicated XML tag. Also, the component-specific properties offer similar characteristics to material parameters, for instance, physical units. Furthermore, XML-based data are advantageous because of a rich ecosystem of libraries and tools, such as GUI based XML editors easing the interaction of XML files, especially important for large files. Additionally, having the parameters available in XML format enables the utilization of XPath queries to conveniently access the data from within the component framework and the actual components.

In the following, we shall adapt the already introduced approach for a general parameter database in the context of the configuration of a component framework. A basic configuration file providing default values - potentially being generated by a GUI-based application to better support end users- with the sole purpose of executing the plugin named ViennaCLLinSol is depicted in the following.

The general plugins region contains the set of all plugins, which should be utilized during the execution (Lines 1-6). Each plugin is defined within its own region (Lines 2-5), which enables to pass parameters to the plugin instance (Figure 5.18). The name of the plugin has to be mentioned within the key region (Line 3), and must match the name as provided by the static ID method provided by the respective plugin (Section 5.3.2).

Figure 5.18: Each plugin possesses its own configuration region within the input configuration file. In this representative case default values for a break-tolerance of for a ViennaCL linear solver component and an iteration limit of iterations for a PETSc linear solver component are used. The values can be accessed from within the plugin by querying the configuration object.