itaps-parallel Notes from today's meeting

[Xiaolin Li]

Karen, I was also there but did not tell you because people were
talking. But I have taken note of everything.

Xiaolin

On Mon, 2010-04-12 at 12:46 -0600, 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
> itaps-parallel at lists.mcs.anl.gov.
> 
> 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.
> 
> 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?)
> 
> 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.
> 
> 
>