The material database is governed by ViennaMaterials, enabling access to different tree-based database backends. In the following we focus primarily on an XML approach provided by the pugixml library.
The following snippet depicts an exemplary XML-based material database file, loaded at run-time.
The depicted XML setup is both highly flexible and readable, however, due to the tag-based nature it is not considered convenient for manual editing especially considering typical sizes of several hundreds of materials. This very fact underlines the importance of flexible database backends. In any case, additional categories and parameters can be easily added. Furthermore, the depicted approach can be extended to support different representations for values, for instance, additionally to the floating-point number a rational number can be stored. Storing different representations may be more suitable under certain circumstances, such as high-precision applications. Also, units are stored, enabling the interfacing application to extract the unit string and use it to form unit-aware physical quantities, providing automatic conversions using, for instance, the UDUNITS package [123]. Although not currently supported, tensor values can be used, by introducing a corresponding tensor XML tag, holding the tensor values. The material database can - upon access - use this particular tag to identify tensor valued data, and use appropriate import routines for reading the tensor values into a tensor object.
The access to data is implemented by using the path-based XPath query language. The values of the selected sub-trees can then be investigated as needed. Therefore, the use of a query language greatly enhances the flexibility of data access. For instance, the following query returns all semiconductor materials present in the database:
Considering the previously depicted minimal material database, the following sub-tree is returned.
The whole node is again returned in XML format. This enables further processing of the returned data using the same mechanisms, using relative query paths, e.g., using the path postfix ".//" instead of "/". This approach can be used to quickly partition and browse large databases.
However, in the case of a material database for simulations, the most common task is to directly access the numerical data values. An XPath query can be evaluated either to a node but also directly to a string, boolean, or a floating-point value. pugixml provides such a mechanism with it’s evaluate_number function. For instance, using this evaluation function the following query yields directly a double value holding the requested parameter when executed on the previously generated sub-tree.
Aside of storing numerical values, we can also store mathematical expressions inside the XML data. These mathematical string-expressions can be evaluated, for instance, by interfacing with the Lua library [124].
The fact that users2 might change the XML input data, such as input files, introduces the need to verify the validity of the XML document. For instance, a material database implementation might expect a setup as introduced above. However, in the problematic case where an advanced user chooses not to follow this setup by, for instance, introducing new tags, it is still valid XML data, but may clash with requirements expected by the database implementation. Therefore, the document type definition ( DTD) can be used, providing a set of markup declarations that define a document structure. Automatic verification of the XML input data relative to a DTD can be achieved by, for instance, utilizing the libxml2 [113] library and its xmlValidateDtd() function.
The query-based access to material data is convenient, however, performing
the query in computational intensive code blocks is not meaningful. For instance,
accessing material data within the mesh element traversal used in assembly routines will
result in a considerable performance hit. Considering meshes with 
elements
would thus translate to 
queries, resulting in considerable look-up times [20].
Therefore, the queries should be conducted outside of such expansive loops, or
- if this is not possible - a cache system, such as least recently used [126], can
be implemented and coupled to the query routines. Such a caching system would
avoid unnecessary look-ups in the database and thus increase overall data access
efficiency.
In general, material data is accessed from various simulation components. For instance, the device - discussed in the following - requires material data to extract parameters such as the relative permittivity for a given material name.