The PIF itself only defines a syntax. It does not prescribe any interpretation of the stored TCAD data. This is one issue which accounts for the flexibility and general-purposeness of the PIF. On the other hand, many ambiguities arise from the possible multilateral description of the same physical problem in terms of PIF syntax. There are many ways to describe a geometry, ambiguities in recognizing a grid or an attribute, and general PIF semantics. These ambiguities arise from different coordinate systems, hierarchical or non-hierarchical geometry specifications and using one or many lists of primitive geometric objects, with or without references to other PLBs. Grids can be of unstructured or tensor product type, defined on a segment or the whole geometry and attributes can be defined on the grid, its points, lines, faces or solids. Moreover, the application interface has to know what to do with different units of measure, when to write and what to reference in a snapshot, geometry or written construct, where to define attributes, what attribute types to use, ....
However, ambiguities and multilateral descriptions are a general problem, because the more general a syntax is and the more functionality a procedural interface has, the more semantic standardizations are needed to make applications work properly in a common environment.
In order to unambiguously interpret PIF data, there have to be both semantic constraints which applications have to adhere to (losing PIF flexibility), and ambiguity resolution mechanisms built into the application interface. The PAI takes care of different coordinate systems through a transformation matrix applied to geometrical data, and accounts for different units of measure through a unit conversion system (e.g. point coordinates can be written in micrometers and read in inches, different spatial axes can have different units). It automatically resolves links to other PLBs and provides a multitude of inquiry functions for locating a certain PIF construct wherever it appears in the PLB.
The more severe semantic differences between simulators (e.g. a simulator working on an unstructured grid coupled to a simulator using a tensor product grid) are dealt with through the high-level libraries and in the PIF ToolBox, comprised of generic PIF tools such as grid generators, interpolators (a prominent representative of which is the VORONOI re-gridding and interpolation service [Hala94]), attribute and geometry manipulators using the PAI and preparing a PLB according to framework-global semantic standards [IuE94]. However, these tools are controlled by the task level and belong to the tool rather than to the data level.
The assembly of solver matrices is not supported by the PAI, since we believe that this task is very problem-specific and current networks don't exhibit the necessary performance to transfer these large amounts of data in an acceptable time frame to a solver server. The ``know how'' of a simulator is always contained in its physical models, the knowledge of which is essential in matrix assembly. A simulator using a standard matrix assembly method would lose much of it's advantages. This holds true for grid generation and the partial differential equation solver too.