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

[Carl Ollivier-Gooch]

Tim Tautges wrote:
> 
> 
> 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?

No, what started the whole conversation was the need to support 
questions like, "How many triangles are there in some set across the 
entire partition?"  and "What are all regions in some set in a 
particular part?"

The proposal I sent out was to overload parts, mesh instances, and 
partitions as the first argument in existing iMesh functions.  This was 
shot down on the basis that it makes multiplexing difficult, at least, 
and perhaps impossible.

The alternative on which we (I think) more or less reached consensus at 
the telecon was to expand the argument lists for relevant functions to 
include a partition handle and a part handle.  For example,

iMesh_getNumOfType(iMesh_instance instance,
                    const iBase_EntitySetHandle entity_set_handle,
                    const PartitionHandle partition_handle,
		   const PartHandle part_handle,
		   const int entity_type,
		   int *num_type, int *err);

Now, I've just done a pass through the iMesh interface to make a list of 
what functions are likely to need this treatment, and here's what I've 
come up with:

Need part, instance, and partition versions:
getNumOfType, getNumOfTopo, getNumEntSets*

The asterisk on getNumEntSets is for partitions: we don't currently have 
defined semantics for identifying logical sets that are spread across 
parts as being one set.  Given that, it isn't clear to me whether asking 
for a partition-wide number of entity sets necessarily gives useful 
information.  This same logic motivates me to leave all of the set stuff 
out, too, on the basis that sets will (under the current paradigm) 
intrinsically are native to an instance (not a part, unless we make a 
change there...), and so talking about adding one set to another on a 
part (for instance) doesn't make sense.  Any thoughts? (Tim, I'm bracing 
myself... :-))

Need part and instance versions, but -not- partition, in keeping with 
our stated aim of not allowing global results that will be absurdly / 
unscalably large:
getAllVtxCoords, getVtxCoordIndex, getAdjEntities, getEntities 
(get2ndAdjEntities will go here, too, once it's added officially)

Need part and instance versions, but -not- partition (IMO), because the 
parallel iteration is again intrinsically unscalable.
initEntArrIter, initEntIter

So the bottom line is that we're looking at, if my count is correct, no 
more than ten functions that will need to be modified in any way.  If 
that small number turns out to really be correct in everyone else's 
view, then it's a manageable enough number that it isn't absolutely 
anathema to -duplicate- a function or two so that the serial interface 
doesn't have to carry around a bunch of null handles as args (or maybe 
we could add a macro to expand something like the current serial version 
to the full version with extra args).

Carl

-- 
------------------------------------------------------------------------
Dr. Carl Ollivier-Gooch, P.Eng.                   Voice: +1-604-822-1854
Associate Professor                                 Fax: +1-604-822-2403
Department of Mechanical Engineering             email: cfog at mech.ubc.ca
University of British Columbia              http://www.mech.ubc.ca/~cfog
Vancouver, BC  V6T 1Z4                  http://tetra.mech.ubc.ca/ANSLab/
------------------------------------------------------------------------