Meeting Minutes - 14 January 2000
General Changes
Some global language design changes affect all methods of field description. The root elements for each method, for instance, are to be given more descriptive names. The changes are :
| Before | After |
|---|---|
<node-information> |
<nodal-field-description> |
<map-information> |
<generalized-field-description> |
<natural-information> |
<natural-field-description> |
Attributes called "index" in the 13/01/2000 minutes will be re-named in some places of the final specification to more accurately mirror their role. In particular this will better differentiate local from global indices, which may cause confusion with node indexing in the traditional nodal description.
Changes to the Natural Field Description
A debate arose over the exact meaning of "over-determined". Rephrasing slightly (this paragraph may well appear in a FieldML specification) :
If the user isn't specifying the ensemble field parameters, then they may want to at least specify the number of ensemble field parameters that a field should be controlled by. Alternatively (or additionally), they may want to specify the order of the element bases in different parts of the mesh. When this information is combined with the continuity constraints a system of nc equations arises in terms of the m ensemble field parameters. If these equations have a rank of less than n (the required number of element field parameters), then the processor may add ensemble field parameters to the field to make the system full-rank, or generate additional constraints. In this case, SVD factorisation will provide map vectors that have the minimum 2-norm. If nc is greater than n, a processor must warn the user, and generate a map that will invariably break some constraints. Least squares map generation (see the generalized FEM documentation for more info) distributes constraint breakage evenly across the mesh.
The <element-bases> element, will need the value "other" added to the elements attribute, for lists of bases which differ across the mesh. For example :
Changes to the Traditional Nodal Description
The most important decision made during this meeting regarding the nodal description was that nodes are properties of a field, and not properties of the mesh. This implies that the node indices within a field description is local to that field, and is not global. This approach allows the combination of fields defined over the same mesh which use a different set of bases/nodes, or have a different node indexing. The disadvantage is that it will be more difficult to select a node based on its global index, as processing software may be forced to re-number nodes in some fields based on the first field read in (probably the best approach). Rules for node re-numbering will not feature in the FieldML specification; these will be application defined.
A small number of simple changes were recommended. Some extra information is required for the specification of the physical representation of field derivatives. To this end a type attribute will be added to <nl-field-derivative>, whose value specifies the nature of the derivative in element coordinates, eg "d/ds1" or "d2/ds1ds2". To make it more obvious that nodes are local to the field, the <node> element will be re-named <field-node>, and its index attribute re-named field-index. In addition, the <global-node-map> element will be re-named <field-node-map>. To make matters confusing, the element indices in the nodal description refer to the global element numbers in the mesh declaration: to clear things up, the index attribute of <element>, will be re-named mesh-index.
In the example given in the 13/01/2000 meeting minutes, the format of the <global-node-map>s are not sufficient to handle cases where a different number of field parameters is specified at different nodes on the same element. As well as indexing the node, we must be able to index the specific field component used as an ensemble field parameter for that element. In the following example of an element declaration, we assume that the <nodal-field-description> has already declared a <node-list> containing at least four nodes indexed from one to four. Within the <field-node-map>, each of the nodes is referenced in turn using a field-node-index attribute in <field-node-ref> elements. If these elements are empty, then it is assumed that the entire vector of field values and derivatives specified at the referenced node is imported into the ensemble field parameter vector for this element. If the <field-node-ref> contains a vector, then this references specific parts of the field vector specified in the referenced nodes.
Another proposed extension is to allow the specification of linear maps within the nodal description method. Consider the current roles of the <field-node-map> and <scale-factors> elements from a generalized FEM point of view. The field-node-map assembles the vector of ensemble field parameters that control the field within the current element. The components of the scale factor vector are multiplied with the
ensemble field parameters to provide the element field parameters that are
input into the basis functions for interpolation. They could also be thought of as the diagonals of a linear map between the ensemble and element field parameters.
In the extension to the nodal method, the <scale-factors> element may be replaced with a <scale-matrix> element which contains a matrix linearly mapping the ensemble field parameters on to the required number of element field parameters. This allows a non-square mapping, where the number of columns of this matrix must match the number of ensemble field parameters created by the <field-node-map>. A non-square mapping can be used to handle complex continuity conditions or hanging nodes. Check out the following (contrived) example where three ensemble field parameters are mapped on to four element field parameters.