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: [email protected] 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