itaps-parallel Mesh Instances

[Onkar Sahni]

Sorry for such a delay in reply, I was out last week and was trying to
catch-up with emails.

Karen, we do not have any restriction as at most one mesh instance,
provided a mesh instance is a mesh database (In FMDB, mesh instance is a
C++ object). I am still not clear on what are differences between
"instance" and "handle" in ITAPS terminology.

In case of the example, where there are hexes. (H) and quads. (Q), if
these mesh entities are related through iMesh adjacency (where user
expects quads. Q to be adjacent to hexs. H through iMesh_getEntAdj or
vice-versa) then one mesh instance would be required otherwise it would be
natural to have two mesh instances. Basically if entities are tied through
"iMesh rules", say through adjacency (not through attached/tagged data),
then one mesh instance will be required.

- Onkar

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