itaps-parallel Mesh Instances

[Devine, Karen D.]

Hi, Mark.

Thanks for your email contributing to this discussion.  (Thanks to Carl,
too!)

It is funny how differently people can read the same email.  I saw Carl's
response as an additional use-case, adding, as he said, complexity but not
providing an answer to my questions about mesh instances.  I agree that for
Carl's example, it is natural to store many submeshes in a single database.
But I keep coming back to the example of a loosely-coupled physics
simulation on multiple distinct meshes, where I think having multiple mesh
instances is more natural.


On 11/19/07 10:16 AM, "Mark Miller" <miller86 at llnl.gov> wrote:

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

Is it really true that is 'best' to manage all mesh pieces within a single
iMesh instance?  This management would be left to the application, I think.
Is it easier for the application to store two distinct meshes in separate
databases, or to store them in a single database, distinguishing between
them with application-managed entity sets, etc.?  I argue that the former is
more natural and easier to use; the application creates a mesh instance for
each distinct mesh.

I do understand that one would like to store different parts of the same
mesh (as in multiblock, adaptively refined, etc.) in the same database.  But
I do not think users would store distinct meshes in the same database, any
more than they would store two distinct meshes in a single Exodus file.

Would a lot of re-implementation really be needed?  The mesh instance is
passed to almost all iMesh functions.  Unless it is ignored by the
implementations, it should provide the mechanism for distinguishing between
separate databases holding distinct meshes.  Am I being naïve?  :)

Thanks again.  Let's all try to get consensus on this topic by Wednesday so
we can proceed with a common understanding.

Karen

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