itaps-parallel Mesh Instances

[Carl Ollivier-Gooch]

Devine, Karen D. wrote:
> In yesterday's meeting, Lori asked me to add our understanding of iMesh
> instances to the background and terminology section of the combined
> document.  I am unable to do so until we come to some agreement on what mesh
> instances are and how they are to be used.
> 
> Let's start with getting agreement for serial applications.
> 
> In the iMesh user guide, I cannot find a definition of what a mesh instance
> represents.  To me as a new(ish) ITAPS user, it looks like it represents a
> single mesh.  If our interface were a C++ interface, I would say that iMesh
> is a class, and that we'd create one iMesh object for each mesh we used in
> the application.  Then we'd invoke methods on each iMesh object as needed.
> For examples, in a loosely coupled physics implementation on two meshes,
> we'd invoke meshOne's methods to do the first set of physics, and meshTwo's
> methods to do the second set of physics.
> 
> In our C interface, we can't invoke methods on an object.  What we do
> instead is what most people do when writing an object-oriented C interface:
> they pass the object to the interface functions.  It is like passing C++'s
> "this" pointer to C functions.
> 
> I think this is a natural way for users of multiple meshes to view the iMesh
> instance, and I don't see anything in the documentation to contradict it.  I
> also think we need to allow multiple iMesh instances to allow multiple
> implementations to be used at the same time via the multiplexer.
> 
> Let's get this serial scenario understood before we move on to parallel.

A slight twist on this (I think) is the notion that a serial mesh 
interface represents a single mesh -database-, which typically contains 
a single mesh, but may (so say the docs) contain a multiblock, 
multigrid, or adaptive refinement -collection- of meshes.  In this 
context, we have talked about a "simple mesh" being just an ordinary 
vanilla single block mesh.  For the more complicated cases, we more or 
less explicitly assume that sets will be used to collect entities that 
lie in different blocks or levels or whatever.  Also, it's possible for 
the mesh database to contain orphaned entities: in a refinement 
scenario, one could choose to keep the parents of split entities around 
for possible later coarsening, although I don't know that anyone is 
actually doing that....

Karen, I apologize for (probably) adding complexity to the issue....

Carl

-- 
------------------------------------------------------------------------
Dr. Carl Ollivier-Gooch, P.Eng.                   Voice: +1-604-822-1854
Associate 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/
------------------------------------------------------------------------