itaps-parallel Two options from today's iMeshP phone conference

[Carl Ollivier-Gooch]

On 10-07-16 04:21 PM, Devine, Karen D wrote:
> Today's attendees:  Carl, Seegyoung, Misbah, Jason, Tim, Vitus, Karen, Mark
> Beall, Saurabh
>
> In today's iMeshP phone conference, we discussed options that would
> associate entities with parts during the entities' creation.  This
> association is desirable to provide consistency of the data base for
> parallel applications and for efficiency in some implementations.  And,
> indeed, for parallel operations to make sense, entities must belong to some
> part.  In addition, we'd like to allow serial iMesh services to be applied
> to all entities in a part; having a mechanism to add entities to a part
> during the creation process allows the serial service to be used.
>
> We discussed services that one might like to use in serial within a part.
> Mesh smoothing was one example; however, because it does not create
> entities, it is not relevant to this discussion.  Other options, like mesh
> generation and edge swapping, need to have some parallel awareness when they
> are used in parallel.  We envisioned that some serial kernels could be used
> under a parallel-aware wrapper for these types of services, provided that
> the serial kernels could add entities to the desired part.
>
> Note that below, I refer to "serial" and "parallel" services.  Serial
> services are those that do not use iMeshP; they view the root set as the
> entire mesh, with no concept of partitions, part boundaries or ghosts.
> Parallel services use iMeshP and recognize that the mesh is distributed
> across one or more processors.
>
> We identified two options:
>
> A.  Change the iMesh_createEnt function to include an entity set handle
> argument PH.  For serial applications, PH would be the root set; that is,
> entities are added only to the root set.  For parallel applications, PH
> would be a part handle; the created entity would be added to the part
> identified by the part handle.  Since iMesh_createEnt is an iMesh function
> (not an iMeshP function), we would use entity set handle as the argument
> type, so that serial users would not have to include iMeshP.h nor link with
> iMeshP.  This option was generally accepted by Carl, Simmetrix, Sandia and
> RPI.  Tim is in favor of adding the argument, but does not like the
> restriction of the handle to be either the root set or a part handle.  My
> fear in allowing arbitrary entity set handles to be used is as follows:  if
> a service uses the entity set handle to, say, add entities to a boundary
> condition set, that service could not be used in parallel, as its
> iMesh_createEnt calls would not add the entities to a part.
>
> B.  Add a new iMeshP function iMeshP_createEnt that takes as input a part
> handle.  Parallel services would need to use iMeshP_createEnt to add
> entities, include iMeshP.h, and link with an iMeshP library; iMesh_createEnt
> would return an error.  Serial services would continue to use
> iMesh_createEnt.  This option is more explicit than option A, but requires
> more work on the user's part if the user wants code to work both with and
> without iMeshP.

I think this is a pretty accurate description.

> One point we didn't discuss but, perhaps, should have was when and how
> entity ownership should be assigned.  The proposed changes add entities to
> parts, but do not address determining the ownership or copy-status of an
> entity.  I am not sure where these issues should most appropriately be
> resolved; can they be postponed until iMeshP_syncPartitionAll?

I had assumed that we were talking about setting ownership, since that's 
the real sticking point: entities that don't have an owner can't be 
modified (as I interpret the current spec).

Carl

-- 
------------------------------------------------------------------------
Dr. Carl Ollivier-Gooch, P.Eng.                   Voice: +1-604-822-1854
Professor                                           Fax: +1-604-822-2403
Department of Mechanical Engineering             email: cfog at mech.ubc.ca
University of British Columbia              http://www.mech.ubc.ca/~cfog
Vancouver, BC  V6T 1Z4                  http://tetra.mech.ubc.ca/ANSLab/
------------------------------------------------------------------------