Introduction

FieldML is an XML-based language for describing time-varying and spatially-varying fields. The language will eventually serve as a replacement for the ".exelem" and ".exnode" files used by CMISS, and is intended to be useful for other groups interested in the field description problem. The aims of the language design process are to keep the language concise, consistent, intuitive and flexible.

Requirements

It is expected that, at the most basic level, FieldML will comprise a set of regions, each including a description of the field within the region.

A good system is needed for describing the relationship between different regions. These relationships can be split up into three types :

Networking : When regions represent physically separate regions, then the relationships between adjacent regions are simple boundaries. This fits in well with the current (November 1999) CellML network description of cellular models (<subspace>, <boundary> and <mechanism>), although that will probably be extended parallel to FieldML. The boundaries can be thought of as regions with one dimension less than the original regions -- this analogy may be useful in relating boundary elements to finite elements (who knows?). Boundaries should probably be treated as a separate type of structure, because the all-important mechanisms linking variables/parameters in two regions can only occur in boundaries.

Grouping : It will frequently be useful to group a number of regions together under a single parent. This parent is not a region itself; it has no area or volume associated with it. Grouping can be used to set properties for a number of regions (though clearly the region must be able to override this if necessary - perhaps a priority switch?), and assign relationships between regions that overlap, touch or don't touch (such as the placement transformations in BeastML.

Embedding : Embedding is a special class of Grouping and represents a physical relationship between two regions whose volumes (or areas) overlap. Embedded regions should automatically inherit the properties of the parent region, unless explicitly overridden. It can be specified that the volume of the parent region may not include the region of the child region (the link essentially forming a Networking boundary in that case.

Example

The following simple example demonstrates how one might arrange regions for a temperature field defined over the heart. At the top level, there is a network of three regions and two boundaries. Within the "heart" region, there is a "heart-muscle" group, containing two regions representing muscle in the left and right ventricles. Within the left ventricular muscle, a coronary network is embedded.

Note that this example doesn't really attempt to address the issue of field description at all - one problem at a time, please.

<field
    name  = "temperature">
  <network
      name  = "whole-heart">
    <region
        name  = "heart">
      <region-group
          name  = "heart-muscle">
        <region
            name  = "left-ventricular-muscle">
          <region
              name  = "left-ventricular-coronary-network" />
        </region>
        <region
            name  = "right-ventricular-muscle" />
      </region-group>
    </region>
    <region
        name  = "left-ventricular-blood-pool" />
    <boundary
        name  = "LV-blood-muscle-boundary" />
    <region
        name  = "right-ventricular-blood-pool" />
    <boundary
        name  = "RV-blood-muscle-boundary" />
  </network>
</field>