FieldML - Current developments
FieldML in CMISS
- Latest Version :
- http://www.physiome.org.nz/fieldml/pages/minutes.html
- This Version :
- http://www.physiome.org.nz/fieldml/pages/minutes_20030305.html
- Authors :
- Shane Blackett (Bioengineering Institute, The University of Auckland)
Contents
Introduction
So, after many years of a static website someone is updating it again. I am a CMISS developer and have been working here in what is now the Bioengineering Institute for about 5 years. The existing file formats used with CMISS are really due for an update and so I have started implementing a version of Fieldml.
In the first instance I want to reproduce the functionality in our existing files but in an XML form. Secondly I do not want to tie the actual definition of the language to our data structures but rather to create a language flexible enough that it can describe our data or and "element" descriptions, including ensemble field parameter descriptions without being encumbered. As far as I can ascertain the existing XML languages for finite elements and data do not attempt to describe the actual interpolations (bases or shape functions) themselves but rely on standard element types to connect nodal quantities to basis functions. In the first instance the files that I will describe here do not include the definition of the basis functions but they do explicitly describe how to form the coefficients for that basis.
The rest of this discussion document is a step through of my first draft of a fieldml file. I have been working on this about 3 months and have CMISS writing and reading these files. The reader is the hard part as I have tried to make this general in that, although CMISS cannot currently store a general element, it reads the file making no assumptions about a particular data structure and then processes the references and templates to see if the element described is one that CMISS can store. The structure of this file is to replace our existing file format.
Fields
The intention here is to keep the field description succint and to declare to entities outside the scope of this document exactly what fields are defined by this document. The value_type is currently an attribute of the whole field rather than each component. This could be relaxed in the language but in CMISS this is currently required.
Nodes
I have explictly included a node element in the language. Essentially
we have a bunch of values that we want to combine together to get the
coefficients of our basis functions. We could just use some generic
label to identify this group of values, for example an label element like
<label name="node_1" />. I have not done this so far for
the following reason.
Often we group those values into nodes, particularly in finite elements
where the nodal values particular
places on our element (in contrast to splines where the control points
do not in general lie on the spine). Even with splines we have these
representative control points which are useful for editing the curve.
A person using our software expects to be able to see and visualise
these nodes as this is the way they are used to thinking about their
element mesh.
So, because the explicit definition of these objects is helpful for
interpreting, visualising and editing the data I have chosen to
explictly specify them.
Each of the values stored in the node is given a name so we can identify
it when we form our basis coefficients in the element.
We often want to have many nodes that have the same names for the
values the contain. To enable use to reuse the label names I define a
template and use this in the node description.
The template equivalent for the node above is similar just without the
values. The <field_ref and <component_ref> elements could considered to be
just another <label name>. I have chosen not to do that so far as I would
like to be able to explictly link the values here with the field defined
at the top. One way to make this link would be to add a type attribute to the <label>
which says that they reference fields, instead I have explictly defined
the <field_ref> element.
After defining the template we can use it to define an actual node.
Basis mapping
To define an interpolation in space I will need a basis function. Each
basis function requires a certain number of coefficients. Rather than a
the relying on the element type defining how to get these values we
will use this language to specify exactly where the coefficients come
from. Ultimately this means that you are explictly stating the node
order in the element. However in this first implementation I have not
specified the definition of the basis and have continued to use the
basis function strings that come from our previous file format, and
these do presume a certain ordering of the coefficients. Ultimately
this string would be replaced by a definition of the actual basis
functions, probably with MathML, so that a program reading this document
could read a Basis Function it has never encountered before and compile
the code necessary to implement them.
Here I have started referencing values that will be described elsewhere
in the document. These I have called lookups, and for each type of
label I have a corresponding lookup element. The element, field and
component lookup do not specify the field or element they correspond to
as this basis mapping could be used by many fields. The mapping may be
referenced several times when defining multiple fields and components on
an element. It is the same field that we are defining that we want to
lookup. This allows us to reuse the basis mapping and enforces a design
decision to not allow you to reference values which are described as
belonging to another field. If you have values which need to be shared
by multiple fields then they cannot be wrapped in a <field_ref> when
the values are defined.
This definition of a basis mapping requires 4*4*2=32 coefficients, and these are made up my multiplying 32 nodal coefficients, 4 from each of 8 different nodes with 32 scale factors specified in the element.
Nodal Values
To match the basis function defined in the previous section we need to extract 32 values from whereever they are stored and compile a list. To lookup values in the node we also need to lookup the name of the node to look inside. Alternatively the values could be stored with the element explictly or even in the field, with each element specifying which field values to extract. This shows one entry out of thirty two.
Interpolation
The next step is to specify which basis mapping and which nodal values to use with which fields.
Element
So finally in the element we need to resolve the <element_lookup>
references and specify which interpolation to use. The <shape>
element is a basis independent description of the elements topology,
I have kept the description from the previous file format but this (like
the basis string) should be a generalised XML form. The <faces>
describe elements which are the shared boundaries between other
elements. This specifies conectivity between elements. I have also
trivially imported this from the previous file format.
E-mail questions, criticism, submissions or info to
Shane Blackett.
|
Last modified: Fri Mar 7 10:56:47 NZDT 2003 |