[Forwarding for archival] -------- Original Message -------- Subject: Re: Subcommittee for Parallel Interface Definition: Global IDs Date: Mon, 15 Oct 2007 13:38:25 -0700 From: Carl Ollivier-Gooch <[email protected]> To: Devine, Karen D. <[email protected]> CC: Onkar Sahni <[email protected]>, Mark Shephard <[email protected]>, Kenneth Jansen <[email protected]>, Tim Tautges <[email protected]>, Vitus Leung <[email protected]>, "Lori A. Diachin" <[email protected]>, Jason Kraftcheck <[email protected]>, "Knupp, Patrick" <[email protected]> References: <C338DFBB.B5CD%[email protected]> Hello, all. Here's my current version of what we need to do about the serial interface to deal with partitioned meshes. Most of it is actually pretty easy; the notable exception is adjacencies, where data requested may or may not be available, and we need to provide appropriate feedback to applications. 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/ ------------------------------------------------------------------------ -- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory ([email protected]) (telecommuting from UW-Madison) phone: (608) 263-8485 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706 Partitioned Meshes Or How to Use Parts in the Current Serial Interface After looking carefully over the current serial interface, I've come to two conclusions: 1. The use of the root set in the serial interface can be viewed as a convention to allow us to query the whole database (in parallel, all data in an instance) and an entity set using the same function. 2. For nearly all functions, we can easily extend that convention to allow part handles a co-equal status with the root set and ordinary entity sets. There are a few exceptions, in my opinion, and also some cases where the semantics of the current interface need extension / reinterpretation. I'm only going to address those cases here. 1. iMesh_getAllVtxCoords, iMesh_getAdjEntities: the in_entity_set argument, when called with a part, indicates whether the -part- owns the vertex / other entity. 2. iMesh_getEntities: As it stands, this should only return owned entities, IMO. We may want to add a flag to allow return of ghosted entities (or, with more nuance, interior, boundary, ghosted, etc, in combinations). In any event, anything that's returned should be returned with a -local- handle. 3. iMesh_getAdjEntities, and other adjacency calls: What to do about adjacencies that aren't in the part? In some cases, that data may be ghosted, and it should be returned if it is. If the data isn't ghosted, then in my view the safest choice is to return a (implementation dependent) null handle and a flag saying that data wasn't returnable (i.e., in_set, not_in_set, not_in_set_and_I_have_no_local_handle). 4. iMesh_getAllVtxCoords: In isolation, this one is pretty safe, because we can interpret this as returning only vertices owned by the part. But currently iMesh_getVtxCoordIndex is supposed to return (a) a list of vertex coordinates for all verts bounding the entities returned by some adjacency call and (b) whether those verts are "in the entity set". The latter is actually easier than the former, since the entities and/or their verts may be non-local and non-ghosted. Our treatment here should be consistent with iMesh_getAdjEntities. In any event, getVtxCoordIndex should be returning local indices. (IMO, part local, not instance local, when called with a part handle.) 5. Set functions. getNumEntSets, genEntSets, addEntSet, rmvEntSet, isEntContained, and isEntSetContained are all perfectly reasonable calls when the entity set that is doing the containing is a part. Most other functions --- including add/rmvEnt and parent-child stuff --- are I think semantic abuse. I'm on the fence about set Boolean ops, just as I was with the root set. 6. Mesh modification. These should, arguably, act on the part, not on the instance, in parallel. After all, if you have multiple parts in an instance, you need to assign new entities to a part at creation time, or you no longer have a partition. IMO, it's more natural to do this all in one go rather than create-then-assign, although implementations can certainly do that internally if they wish. 7. Tags. We can tag sets (including the root set), and we need to be able to tag parts. So we should use the existing interface, and just pass a part handle instead of a set handle. (We could also add another family of functions specifically to tag parts, but I don't think that's necessary. As an aside, we probably are going to need to start making a distinction between groupings of entities that are entity sets and groupings of entities that are parts or instance root-sets. I propose that when we mean all of these things (sets, parts, root sets), we use "collections", and when we mean specifically entity sets, we continue to use "sets". That distinctions may help clean up the semantics of the interface a bit (as well as the documentation). Yes, this means adding two more named opaque types (part handle and collection handle) instead of one, but I think it's a good trade-off for clarity.