itaps-parallel Mesh Instances

[Mark Miller]

Hi Carl,

Thanks for clarifying this. No I really mean it. The notion of 'database'
actually does not appear anywhere in the actual API methods that
users of the ITAPS libs will use to manage scientific data. This is
partly why I was focusing on the meaning of the word 'mesh' in the
ITAPS world. From the point of view of the interface itself, an iMesh
instance is really an instance of something much more than a 'mesh',
it is an instance of a mesh DATABASE which, as you have described below,
can contain one or more meshes or pieces of the same mesh.

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.

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. 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!!)