ML Scope

The purpose of FieldML is to describe a single field over a mesh. In it's parent ML RegionML, multiple fields may be defined over a single mesh. The scope of MeshML is confined to mesh topology (elements and their connectivity).

MeshML Issues

We assume that an element can only have one element coordinate system and that this is defined in the element declaration. This assumption allows connectivity, which relies on local coordinate (or "shape") declaration to also be specified in the mesh definition. Without the assumption, there would not really be any useful information to put in MeshML.

Why define a mesh without a field? Who knows?

We need a system of relating meshes at a variety of resolutions/discretisations, probably in terms of element coordinates. For some problems we will need a notation for describing fine meshes as refinement of coarse meshes for instance, where having identified a material point in terms of element coordinates in one mesh, we can find the same point in other versions of the mesh.

An element is defined by its index, number of element coordinates, and its shape. The index is used for uniquely identifying elements. The number of element coordinates allows for easier processing of the shape, although is not strictly necessary. The shape contains the definition of the element coordinate system for the element (note that this limits but does not define the choice of basis function, which is specified in FieldML.) The shape data is a number of coordinate systems, some interdependent, separated by asterisk (*) characters. Some examples follow :

• line * line * line - your regular rectangular-cartesian coordinate system: of course, cubic basis functions can still be applied.
• polygon(5,2) * polygon * line - the first two element coordinate directions make a 5-sided polygon (the 2 links the first polygon declaration to the second), with a perpendicular linear third element coordinate direction.
• simplex(2) * simplex * simplex(4) * simplex - a 4-dimenionsal simplex element where the 1st and 2nd, and 3rd and 4th element coordinates are tied together.

An example of the element declarations for the elements in the 1-D 3-element example in the generalized fem notes might be [todo : insert better example later]:

<mesh>

  <element>
    <index>1</index>
    <numElementCoordinates>1</numElementCoordinates>
    <shape>line</shape>
  </element>

  <element>
    <index>2</index>
    <numElementCoordinates>1</numElementCoordinates>
    <shape>line</shape>
  </element>

  <element>
    <index>3</index>
    <numElementCoordinates>1</numElementCoordinates>
    <shape>line</shape>
  </element>

</mesh>

Connectivity

Having specified a shape for each elements, we still need to specify the connectivity between the elements in order to properly describe the mesh. There are several approaches that people may wish to use when creating a mesh, and the connectivity definition part of MeshML needs to be flexible enough to deal with each approach. Note that in the following discussion, "face" is synonomous with an element of dimension one less than a mesh element.

Method One : Elements are created with CMGUI. CMGUI then creates a set of faces with unique global face indices. If each element declaration contains the global face indices of each of its faces, then the connectivity is implied by elements sharing the same global index. Connectivity can be determined automatically, by looking for faces on different elements that share the same vertices. In the current system the ordering of faces is known by the CMGUI for each element type, eg a tri-linear element might list faces with x¹ = 0, x¹ = 1, x² = 0 ...

Method Two : The mesh is created with vi or an application (probably a script) other than CMGUI. This application may generate elements but not be familiar with the face ordering required to implement Method One for complex shapes. It would be possible to explicitly specify the face ordering, but Method One still requires the unique indexing of faces over all the elements. Do we need an alternative method for specifying connectivity?

A Demonstration Example

We need a demonstration example that contains some of the problems in meshing and field description that cannot be expressed in the current CMGUI setup. These problems include hanging nodes, ....