rchristie
commented
8 years ago 3-D wedge elements need to be handled too: there are 3 configurations of the tensor product of a triangle with a line element: triangle in xi 1-2, 1-3 and 2-3 directions. It is convenient to refer to faces on the 'line' direction in the same way as for quad/hex elements; for example, consider taking a 2-D mesh consisting of quad and triangle elements and extruding it in the xi 3 direction.
The Zinc API uses an enumeration to refer to faces, but we have currently only implemented the standard line/quad/hex case. I anticipate adding enumerations for the simplex faces (and don't see a need to worry about complications of 4-D tensor products of triangles any time soon).
These enums could be something like:
ELEMENT_FACE_MINUS_XI1 ELEMENT_FACE_PLUS_XI1 ELEMENT_FACE_MINUS_XI2 ELEMENT_FACE_PLUS_XI2 ELEMENT_FACE_MINUS_XI3 ELEMENT_FACE_PLUS_XI3 // for simplex: ELEMENT_FACE_ZERO_NU1 ELEMENT_FACE_ZERO_NU2 ELEMENT_FACE_ZERO_NU3 ELEMENT_FACE_ZERO_NU4
where nu is the barycentric coordinate identified with the linear simplex local node of the same number.
(Having MINUS_XI/PLUS_XI supports elements with xi ranging from -1 to +1, or 0 to 1. Note that the current enums in Zinc are actually XI1_0, XI1_1 etc., but we can move to new agreed names.)
Hence a 3-D wedge with the triangle in the 1-2 plane would have 5 faces:
ELEMENT_FACE_ZERO_NU1 ELEMENT_FACE_ZERO_NU2 ELEMENT_FACE_ZERO_NU3 ELEMENT_FACE_MINUS_XI3 ELEMENT_FACE_PLUS_XI3
The other two wedge configurations would just vary the xi direction for the line part.
Other packages have square-based pyramid elements, which we may want to handle (or will we always use a collapsed hexahedral element?).
FYI Internally, Zinc/Cmgui also has 'polygon' elements which have an arbitrary number of faces around the 1-2 plane. It's long been my intention to phase these out and convert them to a larger number of simplex elements.
chrispbradley
initially when I planned OpenCMISS I decided to, unlike old cmiss, not have the user access lines and faces via a global line or face number. Instead relative references via an element were envisaged e.g., give an element and then a relative reference to identify the desired line or face. Now, some of these references have crept in via local line and face numbers e.g., for a standard quad element there are 6 local faces and 12 local lines. These local references are, however, arbitrary e.g., what is local line 5? Instead the local lines and faces should be referenced via the xi directions normal to the desired line or face. For faces this is straight forward. It would be the index of the xi direction (outward) normal to the face. For quad elements this would be -3,-2,-1,+1,+2,+3 for the 6 faces. For tet elements the direction is given by the local node at the vertex opposite the face. For lines we need two normal xi directions to identify the two faces for which the line is the intersection of. Thus for a tri-linear quad element the xi 1 local line from local node 1 to 2 would be identified by the -3 and -2 xi direction indexes. Than plan would be to change all the APIs such that if the user needed to specify a local/global line or face they would use the element and xi normal indices. Any comments?