Each ITAPS interface encapsulates functionality that "belongs" together, for example mesh or geometric model functionality. In some cases, however, data in several of these interfaces need to be related together. For example, a collection of mesh faces should be related to the geometric model face which they discretize. The ITAPS Relations interface accomplishes this in a way which allows the lower-level interfaces to remain independent.

iRel defines relations as pairwise relations between entities or entity sets. Related entities can be in the same or different interfaces. A given relation is created for a given pair of interfaces and returned in the form of a Relation Handle. After a specific relation pair has been created, concrete relations for that pair can be assigned and retrieved for specific entities using set and get functions on the iRel interface. A given interface instance can appear in one or many relation pairs, each identified by the relation pair handle.

Relation Types

Relations are also distinguished by a pair of relation types. For each interface in a relation pair, a corresponding type indicates whether the relation applies to entities, entity sets, or both entities and sets in the corresponding interface in the pair. If only one of the interfaces in a given pair has a 'both'-type, entities and entity sets in that interface are each related to either entities or sets in the other interface in the pair. If both of the sides of a relation are of 'both'-type, entities and sets on one side of a relation point to sets on the other side.

Relation Status

Relations are also distinguished by a pair of relation statuses. For each interface in a relation pair, a corresponding status indicates whether the relation on that side is kept up to date, or stored at all. Allowable values for status are iRel_ACTIVE, iRel_INACTIVE, and iRel_NOTEXIST, defined in the iRel_RelationStatus enumeration. Status for a given side can be changed from iRel_ACTIVE to iRel_INACTIVE and vice versa, or from either of those to iRel_NOTEXIST. However, once changed to iRel_NOTEXIST (or created that way), a side cannot be changed back to the other two. Changing a side to be iRel_INACTIVE can be used when frequent changes to the underlying entities are being made, e.g. during adaptive mesh refinement. Changing from iRel_INACTIVE to iRel_ACTIVE implies a traversal of all entities on the iRel_ACTIVE side to recover which entities on the iRel_INACTIVE side must have their relations updated.

Argument Order

Many functions in the iRel interface take as input two entities, or two lists of entities, along with a relation pair handle. For these functions, the entities or lists are assumed to be in the same order as the interfaces used to create that relation pair. For example, if a relation pair is created by calling:

 iRel_createRelation(instance, iface1, ent_or_set1, type1, 
                     iface2, ent_or_set2, type2,
                     &relation_handle, &ierr)

and relations set by calling

 iRel_setEntEntRelation(instance, relation_handle,
                        ent1, is_set1, ent2, is_set2, &ierr)

it is assumed that ent1 is contained in iface1 and ent2 in iface2.

For functions taking only one entity or list as input, and returning an entity or list, an additional argument indicates whether the input entity or list belongs to the first or second interface in that relation pair.