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

[Jason Kraftcheck]

Carl Ollivier-Gooch wrote:
> Jason Kraftcheck wrote:
>> Carl Ollivier-Gooch wrote:
> 
> [snip]
> 
>>> In the serial interface, we have lots of queries that take both a 
>>> mesh instance and an entity set argument.  In the now more-or-less 
>>> deprecated SIDL paradigm, the mesh instance in an object (in the C++ 
>>> sense), and we
>>> unified global and entity set calls by creating a root set that is,
>>> essentially, shorthand for "everything in the mesh instance".
> 
> [snip]
> 
>>> 1.  All part handles must be unique, even in the presence of multiple
>>>     partitions.  Pointer-type handles will easily satisfy this;
>>>     integer-type handles may need to reserve some bits for partition ID
>>>     and some for part ID.
>>
>> But then how do we find the data for the partition once we have its 'id'
>> from the part handle?  Look it up in a table?  How do we find the table?
> 
> Yes.  Remember, it's on the -implementation- side that this lookup has 
> to occur, and the implementation can easily keep track of a table of 
> partitions; this have size O(1).
> 

Yes, the natural place to put said table is in the mesh instance.

>> I don't think your proposal is flawed in theory.  However, it is rather
>> difficult to implement in practice.  Your assumption that the
>> mesh_instance part of the interface is a unnecessary legacy from SIDL is
>> incorrect.  For id- or index-type handles, we need the mesh instance as
>> a pointer to the group of data that the handles reference.  We could
>> just as easily remove the mesh_instance argument from the serial
>> interface entirely.  It is possible to embed some "instance id" in the
>> handles, and look up the instance in some static table.  And further, to
>> be consistent, if we can remove the need for the mesh instance in some
>> cases, we should do so for all of them.  This brings us back around to
>> passing part and partition handles as the entity set argument, as that
>> is consistent with the serial interface.  Or to look at it from the
>> other direction:  if all handles are unique across mesh instances, what
>> is a mesh instance?
> 
>> The multiplexer is an example where this would be unworkable.  In the
>> multiplexer, the mesh instance is as pointer to a function table.  It
>> must be able to determine which function from which shared library a
>> given handle is supposed to be passed to.  While we can guarantee that
>> handles are unique within an implementations, there is no way to
>> guarantee that they are unique /between/ implementations.
>>
>> So as I said above, if one only considers the theoretical meaning of a
>> mesh instance, your proposal would work.  However, the mesh instance
>> means something specific for implementations, and is necessary for any
>> non-pointer handle implementation.
> 
> 
> I'm sorry if I gave the impression that I think the mesh instance is "an 
> unnecessary legacy", as that definitely wasn't my intent.  And no, I 
> don't think it's at all reasonable to expect that entity handles be 
> unique across all mesh instances.  With that cleared up, Jason, are
> there any points in the above that still apply?  If so, let me know, and 
> I'll try to respond to them.

I didn't read your initial comment about mesh instances as necessarily 
implying that it is "an unnecessary legacy".  However, your proposal 
implies that.

Whatever mechanism we employ to work around the lack of a mesh instance 
in some cases can be employed in all cases.  We should therefore 
eliminate the mesh instance entirely, rather than making interface 
functions behave drastically differently in some cases.  Further, your 
proposal in practice requires it.  If a part handle is an ID and the 
mesh instance is a pointer, then short writing our own memory allocator, 
there's no way we can prevent the numerical value of the pointer from 
being the same as some part handle.  If in the implementation we cannot 
determine if the passed value is the mesh instance or a part handle, 
then we cannot use a mesh instance in any practical way.

If we remove the mesh instance from the serial interface, we're back to 
needing two set handles to perform the types of queries you're 
proposing.  So why force us to jump through hoops to work without mesh 
instance?  Just add another set handle to the functions if it is 
necessary.

- jason