4.2.2 Material Database

Simulation tools usually require a large set of material parameters to carry out scientific simulations, due to the use of equations which include material parameters to model the physical environment [108][109][110]. Among such equations, partial differential equations are especially widespread in the description of complex phenomena and are therefore of special interest for CSE in general. Considering the vast number of phenomena and the related sets of equations for which simulation environments have been and are currently being developed, it becomes apparent that many different material parameters have to be made available in a consistent and reliable manner. The challenge lies not only in the efficient storage of the material data but also in the convenient and fast data access. For instance, considering the case of carrier mobility, in the simplest case the mobility value for a given material is a constant. However, in more complicated cases, i.e., scattering models, the carrier mobility depends on a set of parameters and the solution variables. The storage and access methods need to support such setups.

Overall, accessing parameters is a fundamental task for CSE applications. In C++ parameters can be provided either during compile-time, by hard-coding them into the implementation, or during run-time, by, for example, feeding the parameters to the application via an input file. Where the compile-time approach is considered to be quick with respect to implementation time, the approach lacks reusability and flexibility. The parameters cannot be easily reused by different applications and changes require recompilation. On the contrary, providing the parameters during run-time allows for changing the parameters without recompilation.

Another challenge is to incorporate unit-aware material parameters which are especially important for robust numerical simulations [111]. Not only need the units be linked to each material parameter in the data set, but also automatic unit checks and - if possible - unit conversions have to take place. Such a unit system must support the dynamic nature of the material parameter database, induced by the fact that material parameters are loaded during run-time. In other words, the unit information is usually available as a string, thus the unit system has to be able to process string-based unit expressions.

Tree-based structures merit special consideration for storing material data. The underlying data associated with materials is inherently hierarchical, and can thus be mapped to a tree naturally (Figure 4.5). Also, the variation due to the fact that not all parameters are available or useful for all materials can also easily be accommodated by a tree-based structure.

Tree-based data structures natively support path-wise data access, due to the supported intuitive descent along the structure of the tree holding the data. Languages which support a tree-based data structure and path-based data access are, for instance, XML via the XML path language ( XPath) query language - as provided by pugixml [112] - or ViennaIPD [37][4]. XML has a distinct advantage, as the language is widespread, thus parameter files can immediately use synergy effects from the large available XML ecosystem, such as GUIs or other well-known XML libraries, like libxml2 [113]. On the contrary, the ViennaIPD language - especially designed for the field of semiconductor device simulation - is more convenient to read due to the absence of tags bounding scoped regions, as is being used by XML. Thus follows the challenge of implementing a flexible device simulator - similar to the previously discussed mesh generation and adaptation case - to facilitate the exchange and addition of material databases. A unified interface is required, ensuring that material database backend changes do not affect the simulation frontend (Figure 4.6).