Yet More Corrections

Yeah, OK, so some of those basis-function sets were pretty poorly named. But that's not to say I can't call them bicubic-linear if I want to - you can use any text string, for God's sake. And you probably wouldn't use a bicubic-monomial basis function set in a traditional nodal description either, for that matter.

Of a bit more importance is an improved method for referencing FieldML objects that have been defined elsewhere. As was pointed out in some previous minutes, the user may want to specify that some of these objects are to be shared rather than duplicated (such as linear map in a generalized FEM field description.) As a reminder, the previous mechanism is given in Figure 1..

The <use-fieldml-object> notation will be replaced by two different elements: <copy-fieldml-object> and <share-fieldml-object>. The first of these indicates to the processing application that the object referenced by the idref attribute should be duplicated internally - this element is generally used to make input files more concise. In some cases when an object's name is critical in referencing, a copied object may need to be re-named, so a rename attribute is also essential. In contrast, the second element indicates that only a single copy of the object referenced should be created, and this object shared between all other objects referencing this one. The <share-fieldml-object> element will be defined for all FieldML objects, but it is up to the application to decide if sharing behaviour is appropriate (and thus supported.) Sharing functionality will be recommended in the final FieldML specification for a limited set of elements including <ee-map> and <generalized-field-description>. An example using the new elements is given in Figure 2.

The other major change (that will also affect field descriptions) is the decision to scrap XML ID and IDREF attribute types. In case you hadn't already noticed, the id attribute on the <define> element has reverted to name, and the idref attribute on the <use-fieldml-object> and <share-fieldml-object> elements has been changed to name-ref. The reason for dropping the in-built XML ID functionality is to reduce restrictions on object naming within FieldML documents from unique names within the document to unique names for distinct element types within the appropriate scope. That is, it is possible to have both a <mesh> and an <element> called "my-element", but it is not appropriate to have two <element>s within the same mesh with the same name. Although the name attribute still carries some of the connotations of a unique identifier, an id attribute would be potentially misleading.

Basic MeshML

Work on MeshML, the part of FieldML relating to the definition of an element set and the connectivity between elements, slowed down over the last month as work on the field description forged ahead. However, it was not forgotten, and returns in these minutes to the limelight.

To re-cover what was discussed in the minutes of 07/12/1999 and 01/12/1999, the most basic mesh definition lists a number of elements, their dimension and their shape. The shape of an element relates to the relative directions of their local coordinates - for instance a polygon local coordinate system contains two polygon components, one radial, and one circumferential. More notes on shape are given in the 01/12/1999 minutes; the only change to the specification of shape is that the local coordinate components should be specified within a vector.

The latest decisions made by the FieldML team relate to the definition of connectivity between elements. The main problems that (are not currently handled) but should be solved are:

• differing local coordinates on adjacent elements sharing a face
• partial face sharing between adjacent elements

In the current CMISS system, a three-dimensional element is built up from its faces, which are in turn built up from lines. Differing local coordinates can be implied by specifying two faces with the same lines, but in a different order. This method corresponds closely to the internal CMISS representation of elements, but is verbose and confusing. Partial face sharing is currently not handled.

The face paradigm is ths most intuitive way of describing connectedness however. To solve the partial face sharing problem, we introduce the idea of a virtual face, which doesn't correspond to an element face but is a virtual plane running through the mesh. Element faces are then mapped to sections of this infinite plane (with coordinate system determined by the user or the application). For the majority of meshes with simple connections between elements, the mapping between element faces and virtual faces will be the identity, and need not be specified. Consider the sample mesh given in Figure 3.

Figure 3. A three element mesh with partial face sharing and differing local coordinates on a shared face.

In Figure 4, the same mesh is exploded into separate elements and the faces relevant to the mesh connectivity specification are labelled. A virtual face is also shown along with its coordinate system, and the mapping between the local coordinates of the relevant element faces is shown in dotted lines.

Figure 4. An exploded version of the three element mesh shown in Figure 3 with faces labelled, and a virtual face defined.

Inter-element connectivity is specified within the mesh definition by declaring <virtual-face> elements. Each virtual face contains a list of the element faces that map on to the virtual face, and if necessary, the mapping itself is also defined within a <connection-map> element. The mesh definition for the mesh in Figure 3 is shown in the FieldML sample code in Figure 5.

If a <connection-map> is specified within a <virtual-face> element, it always maps the previously defined local face on to the parent virtual face. In the sample code in Figure 5, the first connection between the right-hand face of element 1 and the virtual face is the identity, so no connection-map is required. As the virtual face is infinite, an appropriate choice of coordinate system makes it a simple matter to specify meshes with hanging nodes and partial face sharing.

The meaning of the element-name-ref attribute on the <local-face> element should be obvious, but the face-name-ref attribute is not so clear. In version 1.0 of FieldML, the faces on an element will be implicitly ordered based on the shape of an element. The face-name-ref must contain an integer between 1 and the number of faces on the referenced element. In a future specification of FieldML, a means for naming element faces may be provided, making their referencing a simpler problem.