itaps-parallel Mesh Instances

[Jason Kraftcheck]

Devine, Karen D. wrote:
> All:  Thanks for your emails.  I admit I am getting more confused than
> before by this discussion.  So let me try to get a clear answer on the
> simplest serial cases before we move to parallelism and iPartition.
> 
> Suppose a serial multiphysics application has two Exodus files with one mesh
> description in each file.  The application wants a single ITAPS
> implementation (e.g., MOAB) to manage both meshes.  It wants to do
> completely different operations on each mesh.  Suppose one mesh is a 3D
> hexahedral mesh and the other is a 2D quadrilateral mesh.
> 
> A) Should the application create two mesh instances, and ask the
> implementation to load meshInstance1 from ExodusFile1 and meshInstance2 from
> ExodusFile2?  Or ...
> B) Should both Exodus files be loaded into the same instance?
> 

I don't see why we'd want to prohibit either one.  The application should
be able to do whatever is most convenient (and within the capabilities of
the iMesh implementation.)  Of course, mixing different dimensions of data
a) seems odd and b) may not be supported by all implementations.

> For case B, what answer does the following iMesh function return?  How does
> this function determine which mesh it is dealing with?
> 
>    void iMesh_getGeometricDimension(iMesh_Instance instance,
>    int *geom_dim, int *err);
> 

Presumably if the implementation supported loading both these meshes at
the same time, the iMesh API would require it to promote the 2D quad mesh
to a 3D quad mesh (e.g. assign 0.0 to all z coordinates of vertices in the
2D mesh.)

> I assumed that since we pass the mesh instance to each iMesh function,
> implementations can use it to determine which mesh they are to query.  So
> this function would return appropriate info for case A.
> 
> Yes, this example is contrived, but it illustrates my point.  I could think
> of more complex examples, but they would be harder to explain.  This example
> doesn't have to deal with parallelism (yet), or with the multiplexer (since
> a single implementation is used).
> 

I'm still don't understand the motivation for a multiplexer that 'merges'
mesh instances.  If an application was working with two meshes that are as
different as the example above (different dimensionality) it is presumably
doing very different things with them.  Using separate mesh instances
would be a logical way for the application to keep these two meshes
separate,.  It seems unlikely that having to manage two mesh instances
would be a burden for the app, as it would require some mechanism to
distinguish between them anyway.

- jason