These part of the code contains implementation of a problem-specific data structures and algorithms. In addition to the basic domain data model of the kernel the models introduce new data types and associated methods (algorithms).

There are currently two types of models that can be implemented outside of the
kernel: *plugin models* and *server models*. Plugin models are
implemented and executed directly in the client code running locally on user's
workstation. Server models are implemented on a remote computing facility
(Beowulf cluster) but are setup and started from the client.

Plugin models can be used for complex data initialization and
pre-processing that can be needed on the client side. They can also be
used as stand-alone models for problem specific solutions. Each plugin
model consists of *Data structures* and *Methods*. The user
interface to the models consists of *Initializer* and
*Iterator*. Usually both are either implemented by the user or
supplied as additional modules to the kernel. Both initializer and
iterator are invoked by separate buttons on the control panel. The
following plugin models are currently available.

These models allow representation of surfaces of different component objects in a grid-independent manner. Usually the "raw" surface represented by pixels retains the unisotropy of the underlying grid. A grid-independent triangulated mesh of this surface can be created by applying advanced meshing techniques and/or surface transformations.

- Boundary Nodes: a collection of boundary pixels.
- Boundary Contours: a set of line segments connecting each boundary pixel.
- Boundary Mesh: a set of triangles with vertexes coinciding with some of the boundary nodes.

The following methods can be applied to generate and manipulate the boundary data structures described above:

__Boundary grid generator:__generates a boundary mesh on a pixel-by-pixel basis. This is the simples form of mesh generator possible. Some post processing of such a mesh would be needed to create a grid-independent surface representation.__Boundary contouring:__Contours of the boundary surface in three spacial directions are created using a special contouring algorithm. Contour information is stored as a linked list of line segments. This surface representation is more smooth than the boundary grid above, but may still require some post-processing.__Boundary smoother:__Removes spacial un-evenness on the surface, which is of the typical length-scale of one grid-cell size (pixel). Repeated application of the smoother can lead to the shrinking of the object size. For that reason the smoother should be applied in a combination with the inflator (see next).__Boundary elasticity solver:__Solves for the deformations of an elastic surface subjected to the pressure drop across the boundary. Can also be used as a surface pre-processor (inflator) in combination with the smoother to produce grid-independent surface representation.

The boundary data can be rendered using several rendering modes:

__Atoms.__Boundary nodes are represented by small colored balls. This mode can be useful for small domain sizes (<100^{3}__Surface.__The surface is represented in a realistic manner with lighting, hidden surface, texturing enabled. Uses java3d technology.__Wireframe.__The surface is represented by connected line segments. Several options of wireframe generation are available:- Grid: pixel-based wireframe.
- Contours: a smoother contour-based wireframe. Contour plane separation parameter can be specified for large objects.
__Points.__Each boundary node is rendered as a single point. Can be useful for large domain sizes (1000^{3})

The method described here will enable one to convert a pixel-based representation of the geometry to a representation based on a connected set of geometrical elements (cells, faces, edges, nodes). The size of the elements is usually greater than the size of a single grid-pixel.

The method is based on a Generalized Element Method (GEM) currently being developed as a part of MulPhys multi-physics modeling framework (paper 1, paper 2, paper 3) and represents a valuable extension to the geometrical modeling since it links pixel-graphics representation of the geometry to the control-volume representation required for the physical modeling.

The basic kernel geometry model is based on pixel-graphics. This opens
possibility to use very simple and versatile geometry modeling tools.
However, the size of a pixel may be prohibitively small for modeling complex
physical processes on a large scale. For these purposes a sub-division of
space into control-volumes is usually employed. In this method the space is
subdivided into *cells* of arbitrary shape and physical variables are
assigned to each cell in a manner that will provide a certain degree of
continuity of the variables inside the cell and at the cell boundaries. A
cell it typically represented by a polyhedron, and depending on the placement
of a variable inside the cell the variable may be node-based, edge-based,
face-based or central. Considering this, it is convenient to introduce a
*generalized element* (GE) as a geometrical primitive of a variable
dimension, d: node (d=0), edge (d=1), face (d=2) and cell (d=3). The elements
of higher dimension can include elements of lower dimension and those of lower
dimension can belong to those of higher dimension. The number of lower
dimensional elements that a higher dimensional element includes will determine
its *order*. Each variable is then considered to be defined to one
particular element type.

The physical laws are then formulated as a system of algebraic relations
between the variables defined on different elements, which is called the
*discretization scheme*. Since most of the physical laws obey some
locality property, these relations usually span only the neighboring elements.
In this case the matrix of the discretization scheme, determining the
relationships between the variables, is characterized as *sparse*. If
the physical laws are given in a partial differential form, as is often the
case, the discretization scheme is obtained by application of finite-element,
control-volume or finite-difference discretization methods. If the law is
given in an integral form or as a low-dimensional analytical solution (2D duct
flow, surface electro-chemistry, etc.), the discretization scheme can simply
be obtained as an interpolation of the solution to the set of elements.
Following this approach, one can realize a general multi-physics modeling,
which combines complex PDE solvers, and simple analytical approximations in
a single framework.

To adopt the GEM approach one needs to be able to convert the pixel-based representation of the geometry, provided by the kernel model, into a generalized element representation. In other words one needs to establish a mapping between the objects in the pixel space and those described by the space of nodes, edges, faces and cells. Generally, a mapping from the pixel-space to the space of vectorized objects, such as those used in vector graphics, can be established as well.

It should be noted that the problem of mapping from the course-grained representation in the GE space to the fine-grained representation in the pixel-space is almost a trivial task. This is because it can be reduced to the inclusion problem, which is relatively simple, and has a unique solution when the pixel size is much smaller than the cell-size. On the other hand, the problem of subdivision of a pixel-space into generalized elements is not unique. Formally, it can be reduced to an optimization problem, but the solution can be combinatorially complex. A faster solution can be achieved by using heuristic methods where the user supplies some information on the type of elements that are desired in certain regions of space. For example, if the system contains a network of linear structures (optical fiber, struts, air/fuel ducts, etc.) a user can restrict the type of the element to be used on these structures to edges only. This will simplify the mapping procedure.

It is clear however that in this approach the graphical user interface should be extended with the possibility of defining point-like, linear and surface objects. The latter has been partially accounted for in the existing system by several models of the wireframe surface meshing. These models provide the way of defining pixel-independent representation of surfaces, and can be readily used to define surface elements. Realization of node-like elements is almost trivial, as long as each of these can be associated with a single pixel in the pixel-based representation.

For linear elements line drawing module of the GUI is used. In this module each line is represented as a connected set of segments. When the line element mode is on, each line is stored as a linked list of objects, each object containing information on one segment of the line. This information includes pointers to the end-nodes of the segment (points A and B in the figure), cross-sectional area, as well as pointers to the nodes inside the segment, which correspond the boundary points of different objects that the element may cross (point C in the figure).

[Line segment AB, intersecting the boundary between two objects at point C.]

In this way it is possible to account of the interface areas between each line segment and the neighboring objects. This information is essential to account for fluxes of conserved quantities in the system (mass, heat, etc.).

Server models are separate programs compiled and executed on a remote Beowulf cluster. They should include interface modules to communicate with the remote master-gui (RING).

This is a currently used proprietary model for simulations of fuel-cell stacks (NETL/WVU). It was modified to include the module for reading the command and monitoring information from the master-module (GUI).