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

[Carl Ollivier-Gooch]

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

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

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