itaps-parallel Mesh Instances

[Tim Tautges]

Carl Ollivier-Gooch wrote:
> 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....
> 

As a matter of fact, that is being done in Philippe Pebay's streaming 
refiner, which is being ported to ITAPS/MOAB as we speak.

- tim

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

-- 
================================================================
"You will keep in perfect peace him whose mind is
  steadfast, because he trusts in you."               Isaiah 26:3

             Tim Tautges            Argonne National Laboratory
         (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
         phone: (608) 263-8485      1500 Engineering Dr.
           fax: (608) 263-4499      Madison, WI 53706