Specifying faces for data projection

[jennyhelyanwe]

Currently the way to set candidate faces for data projection (DataProjection_ProjectionCandidatesSet) is by inputting an array of element numbers and another array of their corresponding local element faces. These candidate faces are set for all data points. There are several things to change about this:

1. We should have the option to be able to set different candidate faces for each data point.
2. The local face numbering order is currently -xi1, -xi2, -xi3, +xi1, +xi2, +xi3. It would make more sense to use -xi1, +xi1, -xi2, +xi2, -xi3, +xi3 instead.
3. Perhaps instead of specifying face numbers, which are heavily convention-dependent and therefore difficult for users who don't remember the convention, we could allow face specification using xi directions instead.

Also, it would be worthwhile to keep the face specification method consistent across different subroutines.

[rchristie]

FYI The face numbering convention you suggested in point 2 is actually what Zinc, Cmgui have always used. It has some niceties in that the order is the same as you increase element dimension i.e. a line has faces xi1=0, xi1=1; square follows these with xi2=0, xi2=1 and so on. This extends to simplex but here there are further differences between Iron and Zinc in that we refer to the xi coordinates, but Iron uses the barycentric coordinates 'nu' which has one redundant coordinate: for a triangle nu1 = 1 - xi1 - xi2, nu2 = xi1, nu3 = xi2. In Zinc the triangle face numbering is xi1=0, xi2=0, xi1+xi2=1 (higher xi in expression has a higher weight, pushing it later, within that ordering a higher constant in the equation pushes it later). I'd guess for simplices, Iron proceeds in the order of nu coordinates equated to zero, but I'm unsure how wedge (extruded triangle) element faces would be ordered.

So yes, numbering is a convention and Iron and Zinc differ. Through the Zinc API we instead use enumerations e.g. FACE_TYPE_XI1_0 which we eventually convert to an appropriate face number internally. You can see these declared by clicking on the FaceType enum at: http://opencmiss.org/apidoc/zinc/latest/classOpenCMISS_1_1Zinc_1_1Element.html You can see some other definitions for ALL/ANY/NO which have special uses in graphics, but we haven't added any for the simplex coordinates yet (mainly because simplex elements are usually randomly oriented so it's of little use to visualise a face; note that wedge elements with triangle on two xi directions and line on the other do not currently respect the face enumeration in Zinc - it's on the to-do list & useful when the xi direction is consistent orthogonal to the triangles).

[rchristie]

IMO The ideal way to implement this (esp. to handle having different data points searching for different faces) is to define general purpose groups of data points/elements/faces i.e. subdomains. That way you share the functionality for establishing the groups with all other methods needing to use them such as boundary condition specifications. Thereafter the only method needed for the DataProjection class is one which adds associations between a datapoint group and a face group; you could add as many of these as required. Individually storing an arbitrary list of faces for each data point is not practical.

This doesn't avoid the more difficult question of how to specify faces when making a face group. Enums as mentioned above are not really an improvement because the value of the enum then needs to be fixed and unchangable forever if you store the raw numbers (though it could be common between Iron and Zinc even if element face numbers internally are not). A further option we've discussed is making user face numbers global, as they are in Zinc and EX files, i.e. there is a uniquely numbered 'face element' that may be shared with neighbour elements.

Once they exist, these groups can/should be serialised to EX or FieldML files.

[chrispbradley]

At the very least we should define meaningful constants so that the user is not entering unmeaningful numbers. We should also come up with a consistent convention between iron/zinc. As we don't want to deal with a global face numbering scheme (which doesn't really mean much to a user) we want to deal with a relative numbering scheme i.e. to specify a face we talk about an element and then a local face of that element. Ditto for lines. The quad elements are pretty straight forward although there could be some debate as to whether it is a xi=0/xi=1 face or a -xi/+xi face? The collapsed quad elments are also fine, the normal faces follow the quad convention and the collapsed faces are simply not there. As for simplex elements then the face is numbered after the local node that is opposite the face. For a tet then this means there are four faces numbered 1, 2, 3, 4. You can think of that as xi1, xi2, xi3, xi4 if you like?