Onkar Sahni wrote:
So again, I go back to asking: what are the core needs that prevent us from using sets as both parts and partitions? The entity set mechanism was designed with this specific usage in mind. If "sets as both parts and partitions" mean using entity-sets then we have already discussed this in great detail. I think the question in discussion is irrespective of how one implements parts and partitions? If I understood the question right then we need to answer queries which involve a specific part and a specific entity-set (where entity-set may span more than one part, may be local to a process). Now, if it is implied that choosing entity-sets for both parts and partitions allows to use set operations (booleans), outside the interface explicitly by applications, to answer such queries well then applications might as well do it in other equivalent ways (for example, loop over entities in set and ask residence parts to get entities in the entity-sey belonging to a specific part).
Sure, but the implication in the current discussion is that doing booleans in the applications themselves is undesirable. Therefore we are looking for a way to represent these questions in the interface. To that I assert that there are lots of other set booleans that are also likely and possibly more common, and therefore we should design these functions to be more general than just applying to parts and partitions. Examples of these queries include: - boundary condition faces which are owned locally - vertices in a set being smoothed which are also on a model face - elements at one refinement level with faces on the skin
These general queries are not (at least to me) related to "core needs that prevent us from using sets as both parts and partitions".
No, but I'm not sure the part-set booleans under discussion are either (up to now it's been more of an efficiency issue, hasn't it?)
Infact, applications can also ask for intersection (i.e., this+this+that) of all examples queries listed above. I would consider these more "utility" type functions which I hope is not confused with parallel interface ("parts and partitions") and may even be separate form mesh interface (iMesh, serial one) as one can ask these general questions at geometric model level too (iGeom)? Do we use "entity-sets" in iGeom (sorry, I am not familiar with iGeom)?
In the original SIDL interface, entity sets were part of iBase, inherited by both iMesh and iGeom. In that sense, I would expect any extra set functions to also appear in iGeom.
For "utility" type functions, we can easily deal with them by following similar concepts as STL algorithms, like find, sort etc., that take iterators and some operators (may be we can pass in iMesh entity iterators and some iMesh boolean operators). For example,
numBCFacesOwned = count(bcFaceIterBegin,bcFaceIterEnd,&iPart_isEntOwned);
I'm not sure that would work very well, depending on the cost of calls through the interface (I know for a fact a SIDL-based interface like that would be way too expensive). Note that the template-based STL stuff only works in C++ and not across languages, and that's an important class of applications. - tim
- Onkar
-- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory ([email protected]) (telecommuting from UW-Madison) phone: (608) 263-8485 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706