We are in the process of adding the concept of a partitioning and partition groups into SMTK’s Model. Whether this will replace the existing grouping mechanism or co-exist along with it is certainly a topic for discussion.
Proposed Definition of a Partitioning and a Partition Group
A partitioning is a way of grouping the components of a model such that a component is a member of at most one group (called partition group).
A partition group is homogeneous (it contains all components of the same type). For example a partition group would contains only faces or only edges but not both.
A partition group can contain another partition group as long as it satisfies the restriction of component type and it is not already a member of an partition group.
How would Partition Groups work (Proposed)
GUI Behavior
When listing components in the resource view, only components that are not a member of a partition group would be displayed as top level (note that a partition group is itself a component)
Components should be able to be dragged into and out of a partition group
When a component is placed in a partition group, it loses all explicit attribute associations and unique properties including color.
Code Behavior
Should be able to get the partition group that contains a component
Questions
When getting the attributes that are associated to a component, should it also return the attributes associated with the partition group it is a member of?
In code, should you be able to still associated an attribute to a component even if it is a member of a partition group? And if so should the explicit attribute hide an inherited attribute that may conflict with it?
Should we keep our existing grouping mechanism in Model?
Can a partition group be even more restrictive than just on component type? For example, could you partition on a Property as well so having a group of aux geometry that are marked vegetation?
FAQ
Why not just merge the components instead using a partition group?
It would be very difficult to ungroup the components since the act of merging (say model faces) is a lossy operation
In the future the idea would be to support more than one partitioning for the same geometric domain.
I may not understand, but I would think that an attribute that accept components would have all components available to it unless it explicitly filtered for partitions.
Well that’s the issue. Here’s a simple example. Lets assume we have 6 faces (f1 - f6) and two partition groups (g1, g2). Now g1 contains (f1, f2, f3) and g2 contains (f4, f5) and f6 is not in any group. We also have two Temperature Boundary Conditions (T1, T2) which are unique, meaning that only one Temperature can be associated to the same component (in this case faces). T1 is applied to g1 and now the code is going to associate components to T2. I would say that only g2 and f6 could be associated to T2. If the code tried to associate say f1 to T2, we would create an inconsistency (the face can not have 2 temperatures) and I feel it would invalidate the nature of the partition group (the fact that components in the group lose their individuality within the partition).
We must be explicit and very careful about how and when group membership is updated, because if membership relies on things like string properties or attribute item values (which are at least sometimes modified outside of the operation system), required membership changes may be delayed and result in presentation of inconsistent state to users, or inconsistent states during operations which can quickly lead to crashes.
Naming and Set-theoretic Behavior
It would be useful to developers and users if we have different names for
“normal” (unrestricted) groups, G,
partitions (or partition definitions), P, (the set of all components which must be assigned a partition entry), and
partition sets (or partition entries), P_i, (the pieces that make up a partition).
Thus P = \cup_i{P_i} and P_i \cap P_j = \emptyset for i ≠ j. Sometimes in solid modeling people accept a weaker definition and say that either \mu(P_i \cap P_j) = 0 (i.e., that the measure of the intersection must be 0) or \dim(P_i \cap P_j) < \max(\dim(P_i),\dim(P_j)) (i.e., that the intersection of partitions must be of smaller dimension than either input partition) for i≠j. This allows for shared infinitesimal boundaries. This difference can be important when assigning boundary conditions to nodal variables by associating BCs with faces. If two faces have an edge in common, what BC should be assigned to shared nodes? The weaker condition makes sense for cell-centered BCs while the stronger may be required for nodal BCs.
Finally, I would like to note a related mathematical concept to partitions that may eventually be useful: covers. A partition requires mutual exclusivity among its member sets. A cover allows overlap; the only requirement for a cover is that every element of the set being covered is a member of at least one covering set. They mirror partitions in that C \subseteq \cup_i{C_i} but there is no condition on the intersection of the covering sets. Do we want to generalize to represent these as well? An example use case might be a multi-phase simulation where every volume should be assigned at least one but possibly more materials.
@Bob_Obara has also called out before (but I don’t see it in this discussion), that once you define a partition of something, there is a set that may pop in and out of existence to hold unassigned components (i.e., components that are specified as members of the overall partition but not assigned to any partition set/entry).
Should we guarantee that this partition set/entry always exists even when empty and provide programmatic access to it? (I would argue we should; this would make workflows that want this set to be empty an easy way to validate it.)
Is this concept available for use today via the model::Group class? If so how does a partition group enforce the rule that a component can be a member of at most one group?
Nope, sorry, the model resource group is just a collection of model entities, not a partitioning. We have not had time to implement Partitions yet. Also, it is conceivable that Partition/PartitionSet could be implemented in the smtk::resource namespace using a string query filter to indicate the set of things which may be partitioned. Then model and attribute resources could both use them.