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

[Onkar Sahni]

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

I think Carl's proposal discussed mesh-specific operations like
getNumOfType, getNumOfTopo, getAllVtxCoords, getVtxCoordIndex, getEntities
and not "set-operations", as I understand it.

Can we deal with overloading (considering multiplexer too), if we talk in
terms of mesh instances, partition instances and part instances (not
part-handles). The only difference I have learned in all this time between
"handles" and "instances" under ITAPS terminology is that handles can be
id- or index- based (whereas instance cannot be). Actually in Carl's
proposal everything was handle, i.e., mesh-handle, partition-handle and
part-handle, see below.

             / partition handle
getNumOfType| mesh instance    , root set handle   , type, result, err )
             \ part handle        entity set handle

I think we didn't made it clear or may be it got lost in details, that we
can easily handle (with no complication in our implementation) what Carl
has proposed. If overloading makes multiplexer difficult (at best) only,
and not impossible, then I think we should see how much difficulty are we
talking about (may be compare to effort and usability of changing the
existing iMesh interface).

As Mark S. said we are "forcing too much details of implementation data
models into the process of defining the API and its functions".

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

I think we were not worrying about efficiency at this time. We wanted to
address the requirements first (through interface).

- Onkar