[Fwd: Re: itaps-parallel Today's phone conf]

[Jason Kraftcheck]

Onkar Sahni wrote:
> I would like to see feasibility of option (d), which was original proposal
> by Carl of overloading first arg. of iMesh instance with either part or
> partition instances, note considering parts and partitions as instances
> not handles (I do not know all differences between "instance" and "handle"
> under ITAPS terminology except that a handle can be id- or index- based.).
> 

The problem is that for our implementation the part handles /are/
index-based.

Conceptually, a "mesh instance" constitutes:
  a) A "handle space" where all handles within that "instance" are
     unique.
  b) Implementation-specific state necessary to acquire data
     corresponding to a specific handle, maintain necessary
     system resources for the entities in the handle space, etc.

For an implementation that uses pointers for handles, a) is guaranteed
independent of the "instance".  And by embedding the necessary pointer in
entities, b) is easily obtainable from the pointer.  However, for
implementations with index-based handles, a drastically different
implementation is required because the state cannot be obtained directly
from the handle:  the state is required for the handle to be meaningful.
The fact that this issue exists at all implies that the "mesh instance" is
sufficiently different conceptually from anything else that passing
something else in place of it is a confusing hack to the API.

Also, this solution make is implementing the multiplexer impractical, if
not impossible to do efficiently.  And for the SIDL interface, in implies
that we /cannot/ have index-based handles for parts or partitions, that
they must be represented as distinct interface objects.


> If option (d) is out, then I am leaning towards (b) too.
> 

It's probably clear at this point that I much prefer b) to d).

- jason


> - Onkar
> 
>> At this point, we're looking at a comparison between:
>>
>> a)  Adding args to about 10 functions, for both serial and parallel.
>> Requires: universal agreement about what a null handle is, or else
>> definition of an implementation-specific global variable that apps can
>> use to find out what the null handle is for that impl.  Also, for every
>> call, the function has to identify which args it was passed and dispatch
>> accordingly (creating more functions internal to the interface,
>> probably, but not user-visible).  Changes to serial code.
>>
>> b)  Leaving those 10 functions alone in serial, and adding parallel
>> versions.  Requires: adding probably one function for each of the
>> originals in the parallel interface.  My guess from the current document
>> on parallel is that we'll be looking at >100 functions already, so this
>> may or may not be considered significant. Serial code left untouched.
>>
>> c)  Adding some magic to squish three args into one in parallel.
>> Requires: A function to squish (and unsquish, internally) the args;
>> therefore, extra effort for the app and impl for each of those 10
>> functions every time they're called (even in serial, probably).
>> Depending on how the squishing is done, risk of handle collision.
>> Changes to serial code.
>>
>> Personally, I think I'd lean towards b, given these three alternatives,
>> provided of course that my count of the number of functions involved
>> holds up.
>>
>> 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/
>> ------------------------------------------------------------------------
>>
>>
> 
> 


-- 
"A foolish consistency is the hobgoblin of little minds" - Ralph Waldo Emerson