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

[Onkar Sahni]

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

We would not even do entity-set boolean (and produce a new entity-set)
below the interface for such a query. Mostly we will try: given some set,
loop over set, ask each entity in set which part it belongs to.

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

We agreed that this would require communications and mostly will be done
by application outside/above interface.

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

We refer them as handles and/or instances, like part-handle (but not
entity-sets).

- Onkar

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