Personal tools
 

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.

   <fieldml xmlns:fieldml="http://www.physiome.org.nz/fieldml/0.1#" xmlns="http://www.physiome.org.nz/fieldml/0.1#">
    
<!-- Generated by Cmiss -->
    
<field name="coordinates" value_type="real" coordinate_system="rectangular cartesian">
      
<component name="x" />
      
<component name="y" />
      
<component name="z" />
    
</field>
  
</fieldml>

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.

   <fieldml xmlns:fieldml="http://www.physiome.org.nz/fieldml/0.1#" xmlns="http://www.physiome.org.nz/fieldml/0.1#">
    
<node name="1">
       <field_ref ref="coordinates">
        
<component_ref ref="x">
          
<label name="value">
    0.000000e+00
          
</label>
          
<label name="d/ds1">
    1.000000e+00
          
</label>
          
<label name="d/ds2">
    0.000000e+00
          
</label>
          
<label name="d2/ds1ds2">
    0.000000e+00
          
</label>
        
</component_ref>
        
<component_ref ref="y">
          
<label name="value">
    0.000000e+00
          
</label>
          
<label name="d/ds1">
    0.000000e+00
          
</label>
          
<label name="d/ds2">
    1.000000e+00
          
</label>
          
<label name="d2/ds1ds2">
    0.000000e+00
          
</label>
        
</component_ref>
        
<component_ref ref="z">
          
<label name="value">
    0.000000e+00
          
</label>
          
<label name="d/ds1">
    0.000000e+00
          
</label>
          
<label name="d/ds2">
    0.000000e+00
          
</label>
          
<label name="d2/ds1ds2">
    0.000000e+00
          
</label>
        
</component_ref>
      
</field_ref>
    
</node>
  
</fieldml>

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.

   <fieldml xmlns:fieldml="http://www.physiome.org.nz/fieldml/0.1#" xmlns="http://www.physiome.org.nz/fieldml/0.1#">
    
<labels_template name="NodeTemplate1">
      
<field_ref ref="coordinates">
        
<component_ref ref="x">
          
<label name="value" />
          
<label name="d/ds1" />
          
<label name="d/ds2" />
          
<label name="d2/ds1ds2" />
        
</component_ref>
        
<component_ref ref="y">
          
<label name="value" />
          
<label name="d/ds1" />
          
<label name="d/ds2" />
          
<label name="d2/ds1ds2" />
        
</component_ref>
        
<component_ref ref="z">
          
<label name="value" />
          
<label name="d/ds1" />
          
<label name="d/ds2" />
          
<label name="d2/ds1ds2" />
        
</component_ref>
      
</field_ref>
    
</labels_template>
  
</fieldml>

After defining the template we can use it to define an actual node.

   <fieldml xmlns:fieldml="http://www.physiome.org.nz/fieldml/0.1#" xmlns="http://www.physiome.org.nz/fieldml/0.1#">
    
<node name="1">
      
<assign_labels template_name="NodeTemplate1">
  0.000000e+00  1.000000e+00  0.000000e+00  0.000000e+00
  0.000000e+00  0.000000e+00  1.000000e+00  0.000000e+00
  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00
      
</assign_labels>
    
</node>
  
</fieldml>

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.

   <fieldml xmlns:fieldml="http://www.physiome.org.nz/fieldml/0.1#" xmlns="http://www.physiome.org.nz/fieldml/0.1#">
    
<mapping name="BasisMapping1" basis="c.Hermite*c.Hermite*l.Lagrange">
      
<coefficients>
        
<product>
          
<element_lookup>
            
<field_lookup>
              
<component_lookup>
                
<label_lookup indices="ElementNodalValues1" />
              
</component_lookup>
            
</field_lookup>
          
</element_lookup>
          
<element_lookup>
            
<label_lookup indices="ScaleFactorList1" />
          
</element_lookup>
        
</product>
      
</coefficients>
    
</mapping>
  
</fieldml>

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.

   <fieldml xmlns:fieldml="http://www.physiome.org.nz/fieldml/0.1#" xmlns="http://www.physiome.org.nz/fieldml/0.1#">
    
<labels_template name="ElementTemplate1">
      
<node_lookup>
        
<node_index>
          
<element_lookup>
            
<label_lookup indices="ElementNodeList">
              
<label_lookup indices="1" />
            
</label_lookup>
          
</element_lookup>
        
</node_index>
        
<field_lookup>
          
<component_lookup>
            
<label_lookup indices="value" />
          
</component_lookup>
        
</field_lookup>
      
</node_lookup>
................
    
</labels_template>
  
</fieldml>

Interpolation

The next step is to specify which basis mapping and which nodal values to use with which fields.

   <fieldml xmlns:fieldml="http://www.physiome.org.nz/fieldml/0.1#" xmlns="http://www.physiome.org.nz/fieldml/0.1#">
    
<element_interpolation name="ElementInterpolation1">
      
<field_ref ref="coordinates">
        
<component_ref ref="x">
          
<mapping_ref ref="BasisMapping1" />
          
<label name="ElementNodalValues1">
            
<labels_template_ref ref="ElementTemplate1" />
          
</label>
        
</component_ref>
        
<component_ref ref="y">
          
<mapping_ref ref="BasisMapping1" />
          
<label name="ElementNodalValues1">
            
<labels_template_ref ref="ElementTemplate1" />
          
</label>
        
</component_ref>
        
<component_ref ref="z">
          
<mapping_ref ref="BasisMapping1" />
          
<label name="ElementNodalValues1">
            
<labels_template_ref ref="ElementTemplate1" />
          
</label>
        
</component_ref>
      
</field_ref>
    
</element_interpolation>
  
</fieldml>

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.

   <fieldml xmlns:fieldml="http://www.physiome.org.nz/fieldml/0.1#" xmlns="http://www.physiome.org.nz/fieldml/0.1#">
    
<element name="1" shape="line*line*line">
      
<faces>
200001 200002 200004 200005 200008 200009
      
</faces>
      
<element_interpolation_ref ref="ElementInterpolation1" />
      
<label name="ElementNodeList">
 1 2 4 5 7 8 10 11
      
</label>
      
<label name="ScaleFactorList1">
  1.000000e+00  1.000000e+01  1.000000e+01  1.000000e+02  1.000000e+00
  1.000000e+01  1.000000e+01  1.000000e+02  1.000000e+00  1.000000e+01
  1.000000e+01  1.000000e+02  1.000000e+00  1.000000e+01  1.000000e+01
  1.000000e+02  1.000000e+00  1.000000e+01  1.000000e+01  1.000000e+02
  1.000000e+00  1.000000e+01  1.000000e+01  1.000000e+02  1.000000e+00
  1.000000e+01  1.000000e+01  1.000000e+02  1.000000e+00  1.000000e+01
  1.000000e+01  1.000000e+02
      
</label>
    
</element>
  
</fieldml>


E-mail questions, criticism, submissions or info to Shane Blackett.

Last modified: Fri Mar 7 10:56:47 NZDT 2003