next up previous contents
Next: 2.3.3 Model Instances Up: 2.3 Structures of the Previous: 2.3.1.3 Default Value Management


2.3.2 Model Structure

Physical models as well as algorithms in the field of numerical computing and other subjects involved into the information processing within TCAD applications are abstracted by C++ classes derived from the Algorithm Library class Model (Fig. 2.3). The Model class summarizes a number of methods and data structures which implement the concept of aggregating the data structures and functions of an algorithmic concept into a single entity which can be managed by the Algorithm Library.

Figure 2.3: Structure of a Model class
\begin{figure}
\begin{center}
\includegraphics{figures/ModelStructure.eps}\end{center}\end{figure}

Algorithms are implemented with user defined Model classes by inheriting these attributes for the new Model class and extending it with additional data and method members which implement the required functionality. In this context the class definition represents the instruction set describing how the actual objects or Model instances have to be constructed.

The layout of MDL classes can be subdivided into three major parts. The first part contains administrative information for the Algorithm Library:

instance name: Each instance of a Model class is assigned a unique instance name. Thereby the Algorithm Library provides access to Model instances using this instance name without requiring a conventional C++ pointer or reference. This is especially required to gain access to methods, Parameters and documentation of Model instances from within MDL expressions since MDL hides the memory representation of its objects completely from the user.
type information: The Algorithm Library implements runtime type identification capabilities for Model classes. This mechanism is implemented independently from the standard C++ runtime type identification mechanisms and describes exclusively the inheritance hierarchy of Model classes. No difference is made between Model classes written in C++ (Section 2.4) and those defined by using the MDL interpreter (Section 3.2). Another important feature of the MDL-runtime type handling extension is that it allows for the dynamic instantiation of Model and Parameter classes. Together with the aspect that a string representation of the MDL class name of a Model instance is available during runtime, this runtime type identification mechanism is responsible for the seamless integration of the MDL interpreter with the C++ structures of the Algorithm Library.
documentation: Model class definitions include some textual information which can be used to instruct the TCAD engineer or model designer about the implemented algorithm. The Algorithm Library automatically forwards this information to the user when runtime type checks for user defined model instantiations fail. This mechanism is aimed to provide the author of erroneous MDL files with useful and ``human readable'' hints about the required Model and Parameter structures and which of these requirements were not fulfilled by his actual definitions on the input deck. Fig. 2.4 depicts an example for an inheritance tree formed by Model classes. It shows schematically the definition of four Model classes ProcessTemperatureModel, GridAdaptionModel, CoefficientModel, and Coefficient_alpha. The arrows indicate the relationships between the particular classes created by inheritance. Thus the Coefficient_alpha Model class inherits from CoefficientModel and another not further specified Model class. Thus a Coefficient_alpha class may also be referred to as an implementation of the CoefficientModel class and will pass corresponding runtime type checks an instantiation time (Section 2.3.3). In this example the MDL runtime type information does not contain any indication of the standard C++ class 'A', since it is not derived from the basic Model class.

Figure 2.4: Inheritance tree
\begin{figure}
\begin{center}
\includegraphics{figures/ModelHierarchy.eps} \end{center} \end{figure}

The second group of Model class members describes the actual algorithm:

Interface: The interface of a Model class contains a list of Parameter classes used for exchanging data values between the Model class methods and the ``outside world''.
local Parameters: are used to describe the state of a Model instance. Their values are unique for each Model instance and are conserved between consecutive evaluations of its methods.
static Parameters: contain data values which are shared between all instances of a certain Model class type.
methods: The methods of the Model class describe the actual algorithm, the initialization, and the destruction of the Model class resources. Different to the situation with C++ classes Model classes require the definition of the standard constructor which must be implemented to forward the MDL class name of the C++ class to the standard constructor of parent Model classes (Section 2.4 and Section 2.8) to facilitate the MDL runtime type identification. MDL methods are implemented by C++ methods with no argument list (parameters are exchanged using the interface mechanism) and a boolean result type indicating the successful evaluation of the method. By convention the main function of an algorithm should be implemented by the MDL method evaluate. In this text the phrase ``to evaluate a model'' is used when this method of an MDL instance is executed. The init method is another standard definition which has to be implemented for all Model classes. Its task is to declare the MDL interface, local, and static parameters as well as the MDL methods available to the MDL interpreter.

The last group of Model class members is formed by additional C++ member variables and method definitions. While these can not be directly accessed from within MDL expressions, they can be used from within MDL methods defined in C++. Suggestive examples for such class members are subroutines or intermediate results of MDL methods which need not be accessible to the user of the application on the input deck.


next up previous contents
Next: 2.3.3 Model Instances Up: 2.3 Structures of the Previous: 2.3.1.3 Default Value Management
Robert Mlekus
1999-11-14