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

[Tim Tautges]

Onkar Sahni wrote:
>> But the language and constructs used to answer the questions (and to ask
>> the questions) is what we call the data model.  For example, the data
>> model says we pass references to entities back and forth using handles.
>>   As proposed by you, the data model for parts refers to them using
>> integer ids.  I think those ids could just as easily be handles, and
>> your implementation could implement those handles as integers.
> 
> We never proposed that "the data model for parts refers to them using
> integer ids". We don't do that in our existing functional implementation.
> There was a requirement that we need unique identifiers for parts (which
> is unrelated to part-handle or how it is implemented). There was a
> specific question during ITAPS bootcamp at RPI, that how do we take care
> of identifiers for parts and answer was we currently use integers and plan
> to use pair or combination of integers (for cases with multiple parts per 
> process/task of parallel application)

Ok, my mistake, looking back at the pmodel document you do talk about 
iProcPart instances (which at this point are more like handles, I think?)

.
> 
>> So, to go back to my original question, and back to what we had agreed
>> going out of the last bootcamp: why can't we pass part/partition handles
>> into existing functions in place of set handles, and have them
>> interpreted specially if they happen to be part/partition handles?
>> Mark, that wouldn't force you to actually represent parts/partitions as
>> sets; you could interpret set handles in a specific range as
>> part/partition ids.
> 
> We have iterated that in mesh-specific functions under iMesh like ones
> Carl discussed in his proposal, getNumOfType, getNumOfTopo,
> getAllVtxCoords, getVtxCoordIndex, getEntities  (and not entity-set
> specific functions like booleans on sets) we would allow to pass in part-
> and partition-handles (in place of entity-set handle).
> 
>> This would make the question of efficient booleans on the results
>> completely separable from the parallel interface discussion, as well as
>> allowing us to use our current function set dealing with entity sets to
>> also apply to parts/partitions.
> 
> Question under discussion is not on efficient booleans (for entity-sets).
> Our current function set (for parallel interface) doesn't allow for what
> we were trying to address.
> 

The first two items from Karen's summary of the last phone call:

-  We discussed Carl's proposal to overload the mesh instance argument 
with partition instances and/or part handles to perform set operations. 
  Jason expressed concerns that the overloading would make implementing 
the multiplexer difficult (at best), and would complicate the 
implementations as well.

-  Lori proposed adding partition information to the argument lists of 
the existing iMesh set-based functions.  We agreed that we could change 
the iMesh interface, adding partition instance and part handle arguments 
to needed functions.  Serial implementations could pass NULL for these 
arguments.

I'm taking "set operations" to mean booleans, among other things, and 
the efficiency of booleans in the application is, I think, what started 
this conversation.  Am I wrong?

- 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