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

[Tim Tautges]

Carl Ollivier-Gooch wrote:
> Tim Tautges wrote:
>>
>>>> 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?"
> 

Well ok, if you want to get that specific, then yes.  But the second of 
those is certainly a set operation (not necessarily entity sets as in 
the iMesh interface, just intersection/etc. between different lists of 
entities).  And the two questions above are different in the sense that 
one might involve parallel communication and the other doesn't.

So I count three fundamental questions we're passing around in one 
discussion here:

1) Do we want to do booleans on query results below the interface level? 
  An example query would be "What are all regions in some set in a 
particular part?"

2) How do we express and query sets spread across processors?

3) How do we refer to parts and partitions in the interface, and which 
functions do we use to get information about them?

I think we need to sort out these questions at the conceptual level 
before getting into specific functions.  I also think they are separable 
questions and should be treated that way first.  Thoughts?

- tim

> 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
> 

-- 
================================================================
"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