A couple comments on your notes below. mark On Apr 12, 2010, at 2:46 PM, Devine, Karen D wrote:
Notes from 4/12/10 phone conference attended by
RPI: Mark S., S. Yung (spelling?), Ting Uwisc: Tim T, Jason UBC: Carl SNL: Vitus, Karen LLNL: Mark M. Simmetrix: Mark B., Saurabh Tendulkar
Agreed: We will meet again on 4/19 at 8:30am PST.
Action Items:
1. Before our next meeting, write your view of the first big question below and email it to the list. Include pros, cons, how apps will use it, how it will affect implementations, etc. Mail it to [email protected].
2. Read other peoples' write-ups. Definitely reply for clarification of details, but let's save the discussion for the phone call where it is easier to follow.
My notes from the meeting:
Agreed: From the iMeshP perspective, an application will typically have, for a given mesh, one iMesh_instance per process, containing all entities stored on that process. The iMesh_instance may have a partition associated with it, with zero, one or multiple parts per process. The underlying implementation may implement this design in any way desired.
The question we were asking related to this was whether that was the intent of the original iMeshP design. I certainly confirm we agreed that was the original intent. I'll reserve agreement on whether that's actually the best choice.
If I understand correctly, Simmetrix intends to implement multiple parts per process by having, internally, multiple "meshes," each representing a part. The iMesh functions would return results from the union of these meshes; the iMeshP part-specific functions would return results from individual meshes. (Does that sound correct, Mark B. and Saurabh?)
Yes, that is likely how we would deal with that. As discussed it still does leave open issues related to your questions below.
The first big question: Can an entity exist in an iMesh_instance that has a partition without being owned by any part? Discussion: There are several points in iMeshP operations where an entity may not (yet) have a part assignment. For example, entities are created with iMesh_createEnt; they can then be added to a part with iMesh_addEntToSet (overloaded with a part handle). But in-between the two function calls, the entity exists without being in a part. Some think this state is acceptable, with the understanding that parallel operations are not possible on entities that are not in parts. But this state causes problems for some implementations, which assume an entity is always in some part (with a default part assignment set during entity creation). If we require that an entity always be assigned to some part, we'll likely need additional interface functions, such as iMeshP_createEnt that creates an entity and assigns it to a part. Even if we don't have the requirement, we could consider adding such functions as a convenience.
The second big question: How should we enable multiple partitions of a single mesh in iMeshP?
The third question: Should iMeshP_destroyPart should return an error if the part to be destroyed is not empty? The answer to this question depends, to some extent, on our answer to the first big question above. Cons: Requires users to explicitly remove entities from parts before deleting the parts. This operation requires three function calls: iMeshP_getEntities, iMesh_rmvEntFromSet (overloaded with part handle), iMeshP_destroyPart. Pros: Prevents users from shooting themselves in the foot. Users would possibly call iMeshP_getEntities and iMesh_rmvEntFromSet anyway to do migration to new part.