itaps-parallel Mesh Instances

[Tim Tautges]

Mark Miller wrote:
> 
> Now, I am not proposing to change the interface names here. However,
> given that 'mesh instance' sounds so much like a 'single simple mesh' and
> given that an ITAPS iMesh instance is really a mesh DATABASE, we
> need to be *really careful* when we talk about it among ourselves and
> with our customers and users of the ITAPS interface.
> 

Although I try to avoid the word database in this context, among friends 
I strongly agree with Mark's point.  The mesh really is a database in 
this context, i.e. it includes both mesh and metadata.  I like to avoid 
database because true relational database solutions have traditionally 
not done very well representing meshes.

> Now, I would like to ask one more question here; when are two things
> we think of as different meshes really different meshes and when are
> they two different parts of the same mesh? Does the answer to this
> question really matter, at least in an ITAPS iMesh instance context?
> Isn't it always 'best' that whetever the case is, we are able to somehow
> manage all the mesh pieces (be they from same meshes or different
> meshes) within a single iMesh instance? I think Tim has been making
> a case for this. 

Yes, with one caveat.  The reason for having things in the same instance 
is the need for data or functionality naturally "grouped" on those 
things.  For a very low-order multiphysics code, where you're simply 
passing data from one physics module to another at pre-defined 
locations, it might be easy enough to have the application manage the 
multiple instances.  For more complex applications, where you want to 
use not only multiple physics, but also components for solution 
remapping, data searching, and scalable parallel operations, I do think 
it's best to use the single instance solution.

- tim

I think if we are not committed to that, then a lof of the
> stuff the current ITAPS interfaces are designed to do has to get
> re-implemented for the case of multiple iMesh instances, right?
> 
> Mark
> 
> Carl Ollivier-Gooch wrote:
> 
>> 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/
>> ------------------------------------------------------------------------
> 
> --
> Mark C. Miller, Lawrence Livermore National Laboratory
> email: mailto:miller86 at llnl.gov
> (M/T/W) (925)-423-5901 (!!LLNL BUSINESS ONLY!!)
> (Th/F)  (530)-753-8511 (!!LLNL BUSINESS ONLY!!)
> 
> 
> 

-- 
================================================================
"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