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

[Devine, Karen D]

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. 

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?

Please email the list if you think I did not get the descriptions correct.

Karen