The PIF plays a very important role in the VISTA data level. Its ASCII format, first proposed by S. Duvall [Duva88], was modified to meet the requirements of a TCAD framework. It is used as an intersite data exchange format and is, in its binary form [Fasc91c], the database storage format of the data level. Fig. 4.1 shows the logical PIF structure with corresponding object relationships. Note that the majority of the simulation information is carried in the grey shaded geometry, grid and attribute constructs, while the objectGroup and meta objects are important extensions for conveying TCAD-related data. Both the geometry and the grid constructs are built out of primitive geometric objects (points, lines, faces and solids). The geometry construct additionally holds a simulator's point of view of a simulation geometry through segmentList and boundaryList constructs.
Figure 4.1: The logical PIF structure
The attribute construct is used to attach any kind of information to an object. The attributeType subconstruct describes the meaning of an attribute. Thus the PIF attribution mechanism is the most flexible means in attaching information to geometries and grids, since attributes can express anything ranging from a simple descriptive string to a vector field defined on a tensor product grid. With this unified concept there is no separation between fields and attributes necessary, which is another milestone to a clearly structured architecture allowing a simple implementation. Fig. 4.2 shows a materialType attribute defined over a segment and Fig. 4.3 shows a 3D electricField attribute defined over a grid.
In contrast to other approaches, attribute types are semantically standardized to prevent incompatibilities in tool communication (e.g. one tool writing a ``Potential'' attribute, and a second tool trying to read an ``ElectricPotential'' attribute), although each tool is free to define its own local attribute types.