itaps-parallel Proposal for handling queries with parts, sets, and partitions

[Tim Tautges]

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
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706