itaps-parallel Notes from today's meeting

[Mark Beall]

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
> 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.

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.
>
>