Meeting Minutes - 13 January 2000
Changes to General Linear Map Description
To facilitate map sharing within the general linear map description method, we add an attribute to the <use-map-information> and <use-ee-map> elements called share-map. By default (ie. if omitted), its value is "true", but it may be set to "false". In this case, processing applications should duplicate map information for that field component.
Changes to Natural Field Description
In its simplest form, all that is required to define a field is a mesh and some continuity constraints. This means that the specification of global parameters is optional in the natural field description. Given just a set of continuity constraints, the processor is free to choose a set of appropriate basis functions, generate the m continuity constraints in terms of the nelement field parameters from adjacent elements, generate a set of n-m linearly independent combinations of element field parameters that will become the ensemble field parameters, and calculate the ensemble to element field parameter map.
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 an over- or under-determined problem may result for the processing application. In the event that the problem is under-determined, the processor may add ensemble field parameters to the field to make the system full-rank. In the over-determined case, 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.
Some examples of field definition using the natural field description method follow.
Topic for discussion : It appears that the method of specifying global parameters proposed in the 12/01/2000 meeting minutes doesn't allow efficient re-use of "nodes" between fields (the combination of <in-element> and <at-local-coordinates> elements). Would it be better to define a list of locations in the mesh, and then global parameters reference those locations. Something like this
Changes to Nodal Description
The method proposed in the 12/01/2000 meeting minutes needs some modifications before it can define the range of fields currently available in CMGUI. The main modification involves the specification of scale factors. Some notes on scale factors: scale factors are the property of an element and are dependent on the bases used within the element. If different fields require different bases over the same element, they will also require different scale factors. It is also possible that different sets of scale factors will be required for the same set of bases to reflect different continuity conditions.
In the meantime, the need to define several fields at each node has diminished so the notation from the 22/12/1999 and the 12/01/2000 meeting minutes has been integrated. In the following example, a single field component has been specified. A <field-ordering> element within the <node-list> allows the processor to match the components of the vector of field values and derivatives specified in each of the following nodes with their physical representation. At any point in the list, a new field-ordering may be specified, which will then apply to all following node vectors. Each <element> definition contains a set of bases, a map specifying the global nodes that will be used in this element for this field, and a vector of scale factors.
Assuming this form of field definition is satisfactory, the main question to ask is what parts of the defintion would one want to re-use when defining multiple field components over the same mesh. In common cases such as multiple components of the same field that are defined using the same set of bases, each <node-information> will contain a unique <node-list>, but the <element-list> information may be defined elsewhere and re-used. Do scale-factors and bases belong together with a single parent so they may be re-used?