Meeting Minutes - 8 March 2000
Connectivity
Once again, we return to the problem of mesh connectivity. We've spent a couple of months now, banging our heads against virtual faces, and working out how the mapping between element coordinates and face coordinates might be possible for a variety of special cases. All without much success. So we decided to give Poul's alternative a tryout.
Poul had originally suggested (a long, long time ago) that we define connectivity at points on element boundaries. At each "connection point", there is a patch coordinate system, and a mapping between the element coordinates and the patch coordinate may be defined for all element points that meet at a connection point. As we are only attempting to define the relationship between local coordinates in adjacent elements at a point, a linear map is sufficient to provide both the local coordinate mapping as well as the change (derivatives) of the mapping.
Assuming that we don't specify a scheme for defining interpolation between connection points of the maps, the "virtual face" scheme may still be kept for defining connectivity where a one-to-one mapping exists between local coordinates on both sides of a face. The virtual face scheme provides more information than the connection point scheme. One potential problem is the ease with which inconsistent connectvity may be specified using the connection point scheme - this may be dealt with later.
In Figure 1, the four connection points needed to join a simple three element mesh with the standard hanging node problem are marked. The proposed corresponding XML markup for the mesh is given in its most basic form in Figure 2.
Figure 2.The XML markup defining the mesh shown in Figure 1 and its connectivity using the connection point scheme.
Beautiful as the above XML is, it could not be accurately described as concise, although this is not obvious for the example given above. Consider a mesh containing a "brick wall" of elements, as shown in Figure 3. In this mesh, connection points will occur at the ends and midpoints of the top and bottom horizontal boundaries in each element. It would be possible to define the local coordinate vectors for each of these points and make substantial savings by re-using this information. However, it is more intuitive to be able to define points within an element when the element's shape is actually defined, and then reference these points at each connection point.
A possible XML description of this mesh and its connectivity is given in Figure 4.
Figure 4.The XML markup defining the mesh shown in Figure 3 and its connectivity using the connection point scheme, where the positions of element points are defined during mesh definition.
I'm (this is WJH writing) not sure if this really provides any advantages over simply defining local coordinates and re-using them, because of the new element types that are needed here. These are <declare_element_point> and <use_declared_point>. The first is used within the element declaration to define a point within an element (using a vector of local coordinates) and associate a unique name with it. Note that the point is declared instead of defined because defined XML elements are copied in their entirety whenever copied or shared, whereas element points are referenced, but additional information must be added before they are useful (the <in_element> data.) Similary, the previously declared element point is used, rather than copied.
Some astute person may be thinking: why not put the <in_element> and <use_declared_point> information into attributes. The reason is that the order in which these two bits of information are encountered is critical. Whereas the order in which attributes are funneled from an XML parser to a controlling application is frequently not necessarily the order in which they are encountered in the document, child elements are always received in order. Although it has not really been discussed yet, it would be nice if a FieldML processor could read in a document using a single pass (that is, no look-ahead or buffering is required during XML parsing.) Wherever possible, information is placed in the order most useful to a FieldML processor.
A further point for discussion is: do we need the ability to define connection points of a higher dimension in terms of connection points. For example, one could define a connection line as a straight line between two connection points, along which local coordinates and their mapping vary linearly. This is starting to get a bit much like the original CMISS scheme, and is probably not needed.