itaps-parallel Mesh Instances

[Devine, Karen D.]

On 11/19/07 6:45 PM, "Tim Tautges" <tautges at mcs.anl.gov> wrote:
> One thing that might be helpful, coming from a (former) Sandian, is to
> try to think of meshes in broader terms than what can be stuffed into an
> Exodus file (Mark described how Silo and SAF do things, for example).
> Exodus uses blocks both for describing the elements themselves as well
> as their material type, which can be limiting sometimes (and that's
> ignoring sidesets, which are even worse).
> 
> - tim

Hi, Tim.

I agree that Exodus is rather limited.  But I'm trying to sell Sandians on
using the ITAPS interfaces right now, so I need to understand how they work
with Sandia's favorite database.  As a former Sandian, you know this is a
hard sell.  Since Sandians don't care much about fortran, people are already
balking that the interface is C rather than C++ (just imagine if I tried to
sell SIDL!).  So I was trying to determine whether a C++-like interpretation
of an iMesh instance as a mesh object would be appropriate.  From this
discussion, it sounds as if a C++ interpretation of an iMesh instance as a
mesh object is wrong; we have to sell entity sets as the mesh objects.  That
is unfortunate; I think an analogy between an iMesh instance and a mesh
object would be quite natural.  Pushing geometric dimensions into tags and
viewing meshes as entity sets when a "mesh instance" data structure exists
is less natural.  

But since everyone else seems to agree that we should have at most one mesh
instance per implementation, I'll update the document and move on.

Thanks for your patience.

Karen