FieldML - Roadmap

Contents

• Contents
• Status
• Language Development
• API

Status

Many people seem to have differing ideas about what FieldML is. There may need to be several languages to meet these differing intentions.

My objective has been to define a parametric numerical field description language. The structure of the language is very general, which is flexible but makes parsing and conformance difficult.

In this document I have attempted to summarise the steps required to developing FieldML to a useful language.

Language Development

Grids

Currently CMISS .exelem and .exnode define a grid as regularly xi spaced values over an element. This has recently been generalised (so that it is no longer necessarily true that the xi values are regularly spaced). Furthermore other spacings (gauss point distributions) also make sense. It has also been a problem that grid points are treated differently from nodes in cmgui. So going forward I think it makes sense to provide a succinct way of describing an systematic field for nodes. This could be done with a computed field which relates some grid point id to the element xi location or an actual coordinate location. Correspondingly the definition of the interpolation between grid points needs to be able to be specified in a succint systematic way. Currently grids are always linearly interpolated, and their regular structure defines the connectivity. Instead a function could specify the nodes for each element. Also the interpolation could be specified and so grids are just a succinct representation of a normal mesh.

Time coordinate

Time variation provides an additional independent coordinate. This is currently implemented in CMISS by assuming linear interpolation of nodal quantities. Elements cannot be defined varying in time. This seems to be connected to the above discussion on grids in that we do not want to be required to define elements explitly in time but we may want to choose how the interpolation is done and would like to treat the time value as another xi coordinate.

Computed fields

In CMISS computed fields to describe mathematical operations of existing fields. These could be used to generate coordinates of the grid locations above. CellML has evolved into a general mathematical description language and could be used to describe these mathematical relationships. These could then be included in FieldML.

API

API specification

To make this development useful to a wider community a parser API would need to be created..... I imagine the parser will resolve where templates are reused so that the client program may not need to support these sort of compact representations. Each client program will have different sets of basis functions that it understands. Conceivably the client could register all the basis functions it can represent and the API implementation could try and present the parsed objects in a supported format if possible. There will likely be other capabilities that a client may or may not have. The reason for this is that hopefully you would then be able to describe the capabilities of other external finite element programs to the API and have it deliver the mesh in a supported way, avoiding debates such as what the node ordering should be in an element.

Implementation

... and a reference implementation. Currently the only FieldML parser implementation I know of is in CMISS and unfortunately is tightly integrated to the internal data structures. A separation of this should be developed.