Contents
Spatially-varying "finite element" field definitions are commonly imported into cmgui in two parts:
This division is arbitrary since they share a common format able to define both nodes and elements, and the fields defined over them. The extensions ".exnode" and "exelem" are merely conventions for the above uses. Any filename extension is acceptable, and full file names with extensions should always be specified in your scripts and command files.
Nodes with literal field values stored for them do not just support element interpolation, but are widely used to represent any point data, and there need not be any associated elements. You will occasionally see files with the ".exdata" extension which are identical to ".exnode" files but read in with a different command ("gfx read data …") so that the objects and associated fields are put in a different set of node objects referred to within cmgui as data rather than nodes, and which are unable to be interpolated in element fields. Note the current limitation of cmgui that each region consists of one list of node objects, one list of elements, and one list of data points.
Cmgui EX files are human-readable text files which are usually created by export from cm or OpenCMISS. They can also be created by scripts or by hand. Due to their complexity, particularly in defining element interpolation, editing an existing file is usually the easiest way to create new data files by hand.
The format has been around for many years and has several exacting rules which can catch the unwary:
Fortunately, cmgui import commands ("gfx read node/element/data") report the line number in the file at which the first errant text is located (do not confuse this with line element numbers). Unfortunately the actual problem may be earlier: if the previous block was incomplete then the first text of the next block, however correct, will be complained about as not matching the tokens and data expected for the previous block.
The EX format defines fields, nodes, elements and groups (sets of nodes and elements) within regions. These objects belong to their respective region and are independent of similarly identified objects in other regions.
Cmgui version 2.6 (released: May 2009) introduces a "Region" keyword which specifies the path to the region which any following fields and objects are defined within until the next Region keyword or end of file. The format is as follows:
Region: /PATH_TO_REGION
Examples:
! The root region for this file:
Region: /
! Region "joe" within region "bob":
Region: /bob/joe
The region path must always be written as an absolute path from the root region of the file, i.e. as a series of zero or more region names starting with and separated by forward slash "/" characters. Region names must start with an alphanumeric character and contain only alphanumeric characters, underscores '_' and spaces; spaces are not permitted at the start or end of the name. Colons ':' and dots/periods '.' are permitted but discouraged.
Versions of cmgui prior to 2.6 implicitly read data into the root region, and will report an error for the unrecognised "Region" keyword. The first non-comment keyword in post Cmgui 2.6 EX files should be a Region keyword; to maintain compatibility with older files it may alternatively begin with a Group declaration.
With EX files you are free to put many regions (and groups) in the same file, or to keep each region (or group) in separate files. The choice is up to the user, although it is more flexible to use separate files, since commands for reading EX files into cmgui (e.g. gfx read nodes/elements/data) permit the file's root region to be mapped to any region. For maximum flexibility and to avoid potential merge conflicts, it is recommended that you keep your model data out of the Cmgui root region.
Cmgui example a/region_io gives several example EX files defining fields in regions and sub-groups.
The Group keyword indicates that all following nodes and elements until the next Group or Region keyword are "tagged" as belonging to a group (set) of the specified name:
Group name: GROUP_NAME
There can be any number of groups in a single region, each potentially sharing some or all of the same nodes and elements from the region they belong to. Groups are entirely contained within their particular region; groups with the same name in different regions are completely independent.
Groups have the same name restrictions as regions. They are not written as a path - just a single name within the enclosing region.
Older versions of Cmgui required nodes, elements and fields to always be defined within a group (within the implied root region), hence the Group keyword was always the first keyword in the file. Since Cmgui 2.6 this is no longer a limitation.
In older EX files it was common to have fields defined after/within a group declaration. However the grouping only ever applies to nodes and element - fields always belong to the region. It is more common to define the fields with nodes and elements under the region with no group, and list only node and element identifiers with no fields under the groups.
Whether the EX file is listing nodes or elements, there is broad similarity in the way in which they and their field data is listed. It consists of a header declaring the number and details of fields being defined for the respective object type, followed by the definitions of the objects themselves. An example header:
#Fields=1
1) coordinates, coordinate, rectangular cartesian, real, #Components=3
... field data specific to nodes or elements ...
The above header declares a field with the name "coordinates". The field is tagged as usage type "coordinate" - this is a hint which tells cmgui that this field is appropriate for use as a coordinate field. Other values for this hint are "anatomical" for special fibre fields, and "field" for all other fields. By default, cmgui will use the first coordinate field in alphabetical name order for the coordinates of graphics. The coordinates declared in this header are embedded in a rectangular Cartesian coordinate system with 3 real-valued components. The rectangular Cartesian coordinate system is assumed if none is specified. The value type real is frequently omitted as it is the default; other types such as integer, string and element_xi are only usable in node fields and integer for grid-based element fields. More complex declarations are given throughout this document. Note that if there is no header or the header has "#Fields=0", then nodes and elements can be defined or listed for adding to a group without defining fields.
Following each line declaring the main details of a field are the details on each field component including the name and the parameter values to be supplied with each node, or the basis functions and parameter mappings to be supplied with each element. These are described later.
There can be only one field of a given name in a region, but it can be defined on nodes, elements and data in that region provided the field is consistently declared in the header, including same value type, numbers of components and component names.
Note that the #Fields keyword in element field headers are additionally preceded by the following keywords and sub-blocks which are described in later examples:
#Scale factor sets=~
...
#Nodes=~
Since Cmgui version 2.6 EX files containing comments are now able to be read. Comment lines begin with ! (exclamation mark character) and may only be placed in parts of the file where a Region, Group, Shape, Node, Element, Values or #Field header keyword is permitted. Putting comments anywhere else will result in obscure errors or undefined behaviour!
Comments are useful for adding source details or copyright/license information to your files, or to document parts of the file. Cmgui ignores the comment lines: they will not be rewritten when exporting an EX file.
Some example comments preceding other keywords:
! Copyright (C) 2009 The Author
Region: /heart
! This following node is the apex of the heart:
! It has 10 versions of all nodal parameters
Node: 13
Note that errors are reported if you attempt to read EX files with comments into versions of Cmgui prior to 2.6.
Following is an example reading 8 nodes numbered from 1 to 8, with a field "coordinates" giving positions at the corners of a unit cube, adapted from cmgui example a/a2:
Region: /cube
Shape. Dimension=0
#Fields=1
1) coordinates, coordinate, rectangular cartesian, #Components=3
x. Value index=1, #Derivatives=0
y. Value index=2, #Derivatives=0
z. Value index=3, #Derivatives=0
Node: 1
0.0 0.0 0.0
Node: 2
1.0 0.0 0.0
Node: 3
0.0 1.0 0.0
Node: 4
1.0 1.0 0.0
Node: 5
0.0 0.0 1.0
Node: 6
1.0 0.0 1.0
Node: 7
0.0 1.0 1.0
Node: 8
1.0 1.0 1.0
Notes:
A slightly more complex example adds a second field "temperature":
Region: /heated_bar
#Fields=2
1) coordinates, coordinate, rectangular cartesian, #Components=2
x. Value index=1, #Derivatives=0
y. Value index=2, #Derivatives=0
2) temperature, field, rectangular cartesian, #Components=1
1. Value index=3, #Derivatives=1 (d/ds1)
Node: 1
0.0 0.0
37.0 0.0
Node: 2
1.0 0.0
55.0 0.0
Node: 3
2.0 0.0
80.2 0.0
Notes:
The following snippet from example a/a3 shows the nodal parameters held at the apex of the prolate heart model:
#Fields=2
1) coordinates, coordinate, prolate spheroidal, focus=0.3525E+02, #Components=3
lambda. Value index=1,#Derivatives=3 (d/ds1,d/ds2,d2/ds1ds2)
mu. Value index=5, #Derivatives=0
theta. Value index=6,#Derivatives=0, #Versions=10
2) fibres, anatomical, fibre, #Components=3
fibre angle. Value index=16, #Derivatives=1 (d/ds1)
imbrication angle. Value index=18, #Derivatives= 0
sheet angle. Value index=19, #Derivatives=3 (d/ds1,d/ds2,d2/ds1ds2)
Node: 13
0.984480E+00 0.000000E+00 0.000000E+00 0.000000E+00
0.000000E+00
0.253073E+00 0.593412E+00 0.933751E+00 0.127409E+01 0.188932E+01 0.250455E+01 0.373500E+01 0.496546E+01 0.558069E+01 0.619592E+01
-0.138131E+01 -0.117909E+01
0.000000E+00
-0.827443E+00 -0.108884E+00 -0.245620E+00 -0.153172E-01
Notes:
Following is the file "cube_element_xi.exdata" taken from cmgui example a/ar (exnode formats), which defines a node field containing embedded locations within elements:
Group name: xi_points
#Fields=1
1) element_xi, field, element_xi, #Components=1
1. Value index=1, #Derivatives=0
Node: 1
E 1 3 0.25 0.25 0.75
Node: 2
E 1 3 0.25 0.5 0.75
Node: 3
E 1 3 1 0.25 0.75
Node: 4
E 1 3 1 1 1
Node: 5
E 1 3 0 0 0
Node: 6
F 3 2 0.3 0.6
Node: 7
L 1 1 0.4
Notes:
The example a/ar (exnode formats) and a/aq (exelem formats) lists several other special field types including constant (one value for all the nodes it is defined on) and indexed (value indexed by the value of a second integer "index field"), but their use is discouraged and they may be deprecated in time. If such functionality is required, prefer computed fields created with "gfx define field" commands or request indexed functionality on the cmgui tracker.
Elements are objects comprising an n-dimensional (with n>0) coordinate space serving as a material coordinate system charting part or all of a body of interest. The set of elements covering the whole model is referred to as a mesh. We often use the Greek character "xi" to denote the coordinate within each element.
Each element has a shape which describes the form and limits of this coordinate space. Shapes are declared in the EX format are follows:
Shape. Dimension=n SHAPE-DESCRIPTION
Up to three dimensions, the most important shape descriptions are:
Shape. Dimension=0 nodes (no shape)
Shape. Dimension=1 line line shape, xi covering [0,1]
Shape. Dimension=2 line*line square on [0,1]
Shape. Dimension=2 simplex(2)*simplex triangle on [0,1]; xi1+xi2<1
Shape. Dimension=3 line*line*line cube on [0,1]
Shape. Dimension=3 simplex(2;3)*simplex*simplex
tetrahedron on [0,1]; xi1+xi2+xi3<1
Shape. Dimension=3 line*simplex(3)*simplex (and other permutations)
triangle wedge; line on xi1 (etc.)
Pairs of dimensions can also be linked into polygon shapes; see example a/element_types.
The shape description works by describing the span of the space along each xi direction for its dimension. The simplest cases are the line shapes: "line*line*line" indicates the outer or tensor product of three line shapes, thus describing a cube. If the shape description is omitted then line shape is assumed for all dimensions. Simplex shapes, used for triangles and tetrahedra, cannot be simply described by an outer product and must be tied to another dimension; in the EX format the tied dimension is written in brackets after the first simplex coordinate, and for 3 or higher dimensional simplices all linked dimensions must be listed as shown for the tetrahedron shape.
The cmgui shape description is extensible to 4 dimensions or higher, for example the following denotes a 4-dimensional shape with a simplex across dimensions 1 and 2, and an unrelated simplex on dimensions 3 and 4:
Shape. Dimension=4 simplex(2)*simplex*simplex(4)*simplex
Beware that while cmgui can in principle read such high-dimensional elements from exelem files, this has not been tested and few graphics primitives and other features of cmgui will be able to work with such elements.
Elements of a given shape have a set number of faces of dimension one less than their own. A cube element has 6 square faces at xi1=0, xi1=1, xi2=0, xi2=1, xi3=0, xi3=1. Each square element itself has 4 faces, each of line shape. The faces of elements are themselves elements, but they are identified differently from the real "top-level" elements.
The cmgui EX format uses a peculiar naming scheme for elements, consisting of 3 integers: the element number, the face number and the line number, only one of which should ever be non-zero. All elements over which fields are defined or which are not themselves the faces of a higher dimensional element use the first identifier, the element number. All 2-D faces of 3-D elements use the face number and all 1-D faces of 2-D elements (including faces of faces of 3-D elements) use the line number. The naming scheme for faces of 4 or higher dimensional elements is not yet defined. The element identifier "0 0 0" may be used to indicate a NULL face.
Cmgui elements store an array of nodes from which field parameters are extracted for interpolation by basis functions. This local node array can be as long as needed. It may contain repeated references to the same nodes, however it is usually preferable not to do this.
Cmgui elements can also have an array of real-valued scale factors for each basis function (see below).
These two arrays are combined in mapping global node parameters to an array of element field parameters ready to be multiplied by the basis function values to give the value of a field at any "xi" location in the element.
Mappings generally work by taking the field component parameter at index i from the node at local index j and multiplying it by the scale factor at index k for the basis function in-use for that field component. It is also possible to use a unit scale factor by referring to the scale factor at index 0, and to not supply a scale factor set if only unit scale factors are in use.
Global-to-local parameter mappings are at the heart of the complexity in cmgui element field definitions and are described in detail with the examples.
Basis functions are defined in cmgui ex format in a very similar manner to element shapes, by outer (tensor) product of the following functions along each xi axis:
constant constant
l.Lagrange linear Lagrange
q.Lagrange quadratic Lagrange
c.Lagrange cubic Lagrange
c.Hermite cubic Hermite
LagrangeHermite Lagrange at xi=0, Hermite at xi=1
HermiteLagrange Hermite at xi=0, Lagrange at xi=1
l.simplex linear simplex (see below)
q.simplex quadratic simplex (see below)
polygon piecewise linear around a polygon shape
It is not too difficult to extend these functions to higher order and to add other families of interpolation or other basis functions including the serendipity family, Bezier, Fourier etc. We are open to requests for new basis functions on the cmgui tracker.
Lagrange, Hermite, Bezier and many other 1-D basis functions are able to be combined in multiple dimensions by the outer product. This is not the case for simplex, polygon and serendipity families of basis functions which, like element shapes, require linked xi dimensions to be specified.
Some example element bases:
l.Lagrange*l.Lagrange*l.Lagrange trilinear interpolation (8 nodes)
c.Hermite*c.Hermite bicubic Hermite (4 nodes x 4 params)
l.simplex(2)*l.simplex linear triangle (3 nodes)
q.simplex(2;3)*q.simplex*q.simplex quadratic tetrahedron (10 nodes)
c.Hermite*l.simplex(3)*l.simplex cubic Hermite * linear triangle (6 nodes, 2 parameters per node)
constant*constant*l.Lagrange constant in xi1 and xi2, linearly varying in xi3
Most element bases have one basis functions per node which multiplies a single parameter obtained from that node. For instance, a linear Lagrange basis expects 2 nodes each with 1 parameter per field component. A bilinear Lagrange basis interpolates a single parameter from 4 nodes at the corners of a unit square. A 3-D linear-quadratic-cubic Lagrange element basis expects 2*3*4 nodes along the respective xi directions, with 1 basis function and one parameter for each node. A linear triangle has 3 nodes with 1 parameter each; a quadratic triangle has 6 nodes with 1 parameter.
1-D Hermite bases provide 2 basis functions per node, expected to multiple two parameters: (1) the value of the field at the node, and (2) the derivative of that field value with respect to the xi coordinate. If this derivative is common across an element boundary then the field is C¬1 continuous there. Outer products of 1-D Hermite basis functions double the number of parameters per node for each Hermite term. A bicubic Hermite basis expect 4 nodes with 4 basis functions per node, multiplying 4 nodal parameters: (1) value of the field, (2) the derivative of the field with respect to the first xi direction, (3) the derivative with respect to the second xi direction and (4) the double derivative of the field with respect to both directions referred to as the cross derivative. Tri-cubic Hermite bases have 8 basis functions per node, one multiplying the value, 3 for first derivatives, 3 for second (cross) derivatives and a final function multiplying a triple cross derivative parameter.
The ex format requires nodes contributing parameters for multiplication by a basis to be in a very particular order: changing fastest in xi1, then xi2, then xi3, and so on. Note this is not necessarily the order nodes are stored in the element node array, just the order in which those nodes are referenced in the parameter map. In most example files the order of the nodes in the element node list will also follow this pattern.
Cmgui example a/element_types provides a large number of sample elements using complex combinations of basis functions on supported 3-D element shapes.
Following is an example of a coordinate field defined over a unit cube, adapted from example a/a2, with faces and scale factors removed to cut the example down to minimum size, and assuming the cube node file from earlier has already been loaded:
Region: /cube
Shape. Dimension=3 line*line*line
#Scale factor sets=0
#Nodes=8
#Fields=1
1) coordinates, coordinate, rectangular cartesian, #Components=3
x. l.Lagrange*l.Lagrange*l.Lagrange, no modify, standard node based.
#Nodes= 8
1. #Values=1
Value indices: 1
Scale factor indices: 0
2. #Values=1
Value indices: 1
Scale factor indices: 0
3. #Values=1
Value indices: 1
Scale factor indices: 0
4. #Values=1
Value indices: 1
Scale factor indices: 0
5. #Values=1
Value indices: 1
Scale factor indices: 0
6. #Values=1
Value indices: 1
Scale factor indices: 0
7. #Values=1
Value indices: 1
Scale factor indices: 0
8. #Values=1
Value indices: 1
Scale factor indices: 0
y. l.Lagrange*l.Lagrange*l.Lagrange, no modify, standard node based.
#Nodes= 8
1. #Values=1
Value indices: 1
Scale factor indices: 0
2. #Values=1
Value indices: 1
Scale factor indices: 0
3. #Values=1
Value indices: 1
Scale factor indices: 0
4. #Values=1
Value indices: 1
Scale factor indices: 0
5. #Values=1
Value indices: 1
Scale factor indices: 0
6. #Values=1
Value indices: 1
Scale factor indices: 0
7. #Values=1
Value indices: 1
Scale factor indices: 0
8. #Values=1
Value indices: 1
Scale factor indices: 0
z. l.Lagrange*l.Lagrange*l.Lagrange, no modify, standard node based.
#Nodes= 8
1. #Values=1
Value indices: 1
Scale factor indices: 0
2. #Values=1
Value indices: 1
Scale factor indices: 0
3. #Values=1
Value indices: 1
Scale factor indices: 0
4. #Values=1
Value indices: 1
Scale factor indices: 0
5. #Values=1
Value indices: 1
Scale factor indices: 0
6. #Values=1
Value indices: 1
Scale factor indices: 0
7. #Values=1
Value indices: 1
Scale factor indices: 0
8. #Values=1
Value indices: 1
Scale factor indices: 0
Element: 1 0 0
Nodes:
1 2 3 4 5 6 7 8
Notes:
#Nodes= 8
Following are 8 sets of three lines each indicating the index of the node in the element"s node array from which parameters are extracted (in this case the uncomplicated sequence 1,2,3,4,5,6,7,8), the number of values to be extracted (1), the index of the each parameter value in the list of parameters for that field component at that node and the index of the scale factor multiplying it from the scale factor array for that basis, or zero to indicate a unit scale factor:
1. #Values=1
Value indices: 1
Scale factor indices: 0
As mentioned earlier, the nodes listed in the mapping section must always follow a set order, increasing in xi1 fastest, then xi2, then xi3, etc. to match the order of the basis functions procedurally generated from the basis description.
The above example is not ready to be fully visualised in cmgui because it contains no definitions of element faces and lines. Cmgui requires these to be formally defined because it visualises element surfaces by evaluating fields on face elements, and element edges via line elements. The command "gfx define faces ..." can create the faces and lines after loading such a file. Alternatively they can be defined and referenced within the ex file as in the following:
Region: /cube
Shape. Dimension=1
Element: 0 0 1
Element: 0 0 2
Element: 0 0 3
Element: 0 0 4
Element: 0 0 5
Element: 0 0 6
Element: 0 0 7
Element: 0 0 8
Element: 0 0 9
Element: 0 0 10
Element: 0 0 11
Element: 0 0 12
Shape. Dimension=2
Element: 0 1 0
Faces:
0 0 3
0 0 7
0 0 2
0 0 10
Element: 0 2 0
Faces:
0 0 5
0 0 8
0 0 4
0 0 11
Element: 0 3 0
Faces:
0 0 1
0 0 9
0 0 3
0 0 5
Element: 0 4 0
Faces:
0 0 6
0 0 12
0 0 7
0 0 8
Element: 0 5 0
Faces:
0 0 2
0 0 4
0 0 1
0 0 6
Element: 0 6 0
Faces:
0 0 10
0 0 11
0 0 9
0 0 12
Shape. Dimension=3
Element: 1 0 0
Faces:
0 1 0
0 2 0
0 3 0
0 4 0
0 5 0
0 6 0
Nodes:
1 2 3 4 5 6 7 8
Likewise scale factors can be read in as listed in the cube.exelem file from cmgui example a/a2, however with Lagrange basis functions the scale factors are all unit valued, so this is rather needless.
The following tricky example collapses a square element to a triangle by using the third local node twice:
Region: /collapse
Shape. Dimension=0
#Fields=1
1) coordinates, coordinate, rectangular cartesian, #Components=2
x. Value index=1, #Derivatives=0
y. Value index=2, #Derivatives=0
Node: 1
0.0 0.0
Node: 2
1.0 0.0
Node: 3
0.5 1.0
Shape. Dimension=1 line
Element: 0 0 1
Element: 0 0 2
Element: 0 0 3
Shape. Dimension=2 line*line
#Scale factor sets=0
#Nodes=3
#Fields=1
1) coordinates, coordinate, rectangular cartesian, #Components=2
x. l.Lagrange*l.Lagrange, no modify, standard node based.
#Nodes= 4
1. #Values=1
Value indices: 1
Scale factor indices: 0
2. #Values=1
Value indices: 1
Scale factor indices: 0
3. #Values=1
Value indices: 1
Scale factor indices: 0
3. #Values=1
Value indices: 1
Scale factor indices: 0
y. l.Lagrange*l.Lagrange, no modify, standard node based.
#Nodes= 4
1. #Values=1
Value indices: 1
Scale factor indices: 0
2. #Values=1
Value indices: 1
Scale factor indices: 0
3. #Values=1
Value indices: 1
Scale factor indices: 0
3. #Values=1
Value indices: 1
Scale factor indices: 0
Element: 1 0 0
Faces:
0 0 1
0 0 2
0 0 3
0 0 0
Nodes:
1 2 3
Notes:
The cmgui example a/testing/simplex defines two fields on a triangle element, one using a 6-node quadratic simplex, the other a 3-node linear simplex basis. The element in that example stores 6 nodes in its node array, only 3 of which are used for the linear basis, but all 6 contribute parameters to the quadratic interpolation.
Example a/element_types has both linear and quadratic tetrahedra.
At the more complex end of the scale is this excerpt from the prolate heart model from cmgui example a/a3. It defines two element fields using different basis functions for each field component. It was exported from cm which always uses a full complement of scale factors i.e. one per basis function.
Shape. Dimension=3
#Scale factor sets= 4
c.Hermite*c.Hermite*l.Lagrange, #Scale factors=32
l.Lagrange*l.Lagrange*l.Lagrange, #Scale factors=8
l.Lagrange*l.Lagrange*c.Hermite, #Scale factors=16
l.Lagrange*c.Hermite*c.Hermite, #Scale factors=32
#Nodes= 8
#Fields=2
1) coordinates, coordinate, prolate spheroidal, focus= 0.3525E+02, #Components=3
lambda. c.Hermite*c.Hermite*l.Lagrange, no modify, standard node based.
#Nodes= 8
1. #Values=4
Value indices: 1 2 3 4
Scale factor indices: 1 2 3 4
2. #Values=4
Value indices: 1 2 3 4
Scale factor indices: 5 6 7 8
3. #Values=4
Value indices: 1 2 3 4
Scale factor indices: 9 10 11 12
4. #Values=4
Value indices: 1 2 3 4
Scale factor indices: 13 14 15 16
5. #Values=4
Value indices: 1 2 3 4
Scale factor indices: 17 18 19 20
6. #Values=4
Value indices: 1 2 3 4
Scale factor indices: 21 22 23 24
7. #Values=4
Value indices: 1 2 3 4
Scale factor indices: 25 26 27 28
8. #Values=4
Value indices: 1 2 3 4
Scale factor indices: 29 30 31 32
mu. l.Lagrange*l.Lagrange*l.Lagrange, no modify, standard node based.
#Nodes= 8
1. #Values=1
Value indices: 1
Scale factor indices: 33
2. #Values=1
Value indices: 1
Scale factor indices: 34
3. #Values=1
Value indices: 1
Scale factor indices: 35
4. #Values=1
Value indices: 1
Scale factor indices: 36
5. #Values=1
Value indices: 1
Scale factor indices: 37
6. #Values=1
Value indices: 1
Scale factor indices: 38
7. #Values=1
Value indices: 1
Scale factor indices: 39
8. #Values=1
Value indices: 1
Scale factor indices: 40
theta. l.Lagrange*l.Lagrange*l.Lagrange, decreasing in xi1, standard node based.
#Nodes= 8
1. #Values=1
Value indices: 1
Scale factor indices: 33
2. #Values=1
Value indices: 1
Scale factor indices: 34
3. #Values=1
Value indices: 1
Scale factor indices: 35
4. #Values=1
Value indices: 1
Scale factor indices: 36
5. #Values=1
Value indices: 1
Scale factor indices: 37
6. #Values=1
Value indices: 1
Scale factor indices: 38
7. #Values=1
Value indices: 1
Scale factor indices: 39
8. #Values=1
Value indices: 1
Scale factor indices: 40
2) fibres, anatomical, fibre, #Components=3
fibre angle. l.Lagrange*l.Lagrange*c.Hermite, no modify, standard node based.
#Nodes= 8
1. #Values=2
Value indices: 1 2
Scale factor indices: 41 42
2. #Values=2
Value indices: 1 2
Scale factor indices: 43 44
3. #Values=2
Value indices: 1 2
Scale factor indices: 45 46
4. #Values=2
Value indices: 1 2
Scale factor indices: 47 48
5. #Values=2
Value indices: 1 2
Scale factor indices: 49 50
6. #Values=2
Value indices: 1 2
Scale factor indices: 51 52
7. #Values=2
Value indices: 1 2
Scale factor indices: 53 54
8. #Values=2
Value indices: 1 2
Scale factor indices: 55 56
imbrication angle. l.Lagrange*l.Lagrange*l.Lagrange, no modify, standard node based.
#Nodes= 8
1. #Values=1
Value indices: 1
Scale factor indices: 33
2. #Values=1
Value indices: 1
Scale factor indices: 34
3. #Values=1
Value indices: 1
Scale factor indices: 35
4. #Values=1
Value indices: 1
Scale factor indices: 36
5. #Values=1
Value indices: 1
Scale factor indices: 37
6. #Values=1
Value indices: 1
Scale factor indices: 38
7. #Values=1
Value indices: 1
Scale factor indices: 39
8. #Values=1
Value indices: 1
Scale factor indices: 40
sheet angle. l.Lagrange*c.Hermite*c.Hermite, no modify, standard node based.
#Nodes= 8
1. #Values=4
Value indices: 1 2 3 4
Scale factor indices: 57 58 59 60
2. #Values=4
Value indices: 1 2 3 4
Scale factor indices: 61 62 63 64
3. #Values=4
Value indices: 1 2 3 4
Scale factor indices: 65 66 67 68
4. #Values=4
Value indices: 1 2 3 4
Scale factor indices: 69 70 71 72
5. #Values=4
Value indices: 1 2 3 4
Scale factor indices: 73 74 75 76
6. #Values=4
Value indices: 1 2 3 4
Scale factor indices: 77 78 79 80
7. #Values=4
Value indices: 1 2 3 4
Scale factor indices: 81 82 83 84
8. #Values=4
Value indices: 1 2 3 4
Scale factor indices: 85 86 87 88
Element: 1 0 0
Faces:
0 1 0
0 2 0
0 3 0
0 4 0
0 5 0
0 6 0
Nodes:
19 82 14 83 5 52 1 53
Scale factors:
0.1000000000000000E+01 0.2531332864778986E+02 0.3202170161207646E+02 0.8105758567679540E+03 0.1000000000000000E+01
0.2540127674788437E+02 0.3851739595427941E+02 0.9783910342424932E+03 0.1000000000000000E+01 0.2665607536220107E+02
0.2913687357203342E+02 0.7766746977550476E+03 0.1000000000000000E+01 0.2797776438705370E+02 0.3675988075068424E+02
0.1028459282538834E+04 0.1000000000000000E+01 0.3107367883817446E+02 0.3665266951220884E+02 0.1138933280984126E+04
0.1000000000000000E+01 0.3053066581298630E+02 0.4220277992007600E+02 0.1288478970118849E+04 0.1000000000000000E+01
0.3612724280632425E+02 0.3339669014010959E+02 0.1206530333619314E+04 0.1000000000000000E+01 0.3620256762563091E+02
0.3810870609422361E+02 0.1379633009501423E+04
0.1000000000000000E+01 0.1000000000000000E+01 0.1000000000000000E+01 0.1000000000000000E+01 0.1000000000000000E+01
0.1000000000000000E+01 0.1000000000000000E+01 0.1000000000000000E+01
0.1000000000000000E+01 0.8802929891392392E+01 0.1000000000000000E+01 0.7673250860396258E+01 0.1000000000000000E+01
0.1368084332227282E+02 0.1000000000000000E+01 0.1181772996260416E+02 0.1000000000000000E+01 0.8802929891392392E+01
0.1000000000000000E+01 0.7673250860396258E+01 0.1000000000000000E+01 0.1368084332227282E+02 0.1000000000000000E+01
0.1181772996260416E+02
0.1000000000000000E+01 0.3202170161207646E+02 0.8802929891392392E+01 0.2818847942941958E+03 0.1000000000000000E+01
0.3851739595427941E+02 0.7673250860396258E+01 0.2955536416463978E+03 0.1000000000000000E+01 0.2913687357203342E+02
0.1368084332227282E+02 0.3986170022398609E+03 0.1000000000000000E+01 0.3675988075068424E+02 0.1181772996260416E+02
0.4344183441691171E+03 0.1000000000000000E+01 0.3665266951220884E+02 0.8802929891392392E+01 0.3226508800483498E+03
0.1000000000000000E+01 0.4220277992007600E+02 0.7673250860396258E+01 0.3238325173328371E+03 0.1000000000000000E+01
0.3339669014010959E+02 0.1368084332227282E+02 0.4568948852893329E+03 0.1000000000000000E+01 0.3810870609422361E+02
0.1181772996260416E+02 0.4503583978457821E+03
Notes:
Cmgui and its EX files also support storage of regular grids of real or integer values across elements. The grid is assumed regular across N divisions on lines, N*M divisions on squares and N*M*P divisions on cubes.
Per-element constants are a special case using constant bases together with 0 grid divisions. These have only been supported since Cmgui 2.7 (April 2010). See this extract from cmgui example a/element_constants:
1) temperature, field, rectangular cartesian, #Components=1
value. constant*constant*constant, no modify, grid based.
#xi1=0, #xi2=0, #xi3=0
Element: 1 0 0
Values :
48.0
Linear Lagrange interpolation is used when there are 1 or more element divisions. Following is an excerpt from cmgui example a/aq "element formats":
Group name: block
Shape. Dimension=3
#Scale factor sets=0
#Nodes=0
#Fields=2
1) material_type, field, integer, #Components=1
number. l.Lagrange*l.Lagrange*l.Lagrange, no modify, grid based.
#xi1=2, #xi2=3, #xi3=2
2) potential, field, real, #Components=1
value. l.Lagrange*l.Lagrange*l.Lagrange, no modify, grid based.
#xi1=2, #xi2=3, #xi3=2
Element: 1 0 0
Values:
1 1 3
1 1 3
1 2 3
1 2 2
1 1 3
1 1 3
1 2 3
2 2 2
1 3 3
1 3 3
2 2 3
2 2 2
13.5 12.2 10.1
14.5 12.2 10.1
15.5 12.2 10.1
16.5 12.2 10.1
12.0 11.0 10.0
13.0 11.0 10.0
14.0 11.0 10.0
15.0 11.0 10.0
10.5 10.7 9.9
11.5 10.7 9.9
12.5 10.7 9.9
13.5 10.7 9.9
Notes:
Further information about cmgui and its data formats can be found on the following web-site:
We also invite questions, bug reports and feature requests under the tracker at:
https://tracker.physiomeproject.org
Note: be sure to search and post under the "cmgui" project!