itaps-parallel New requirements proposed for iMeshP: bootcamp discussion

[Devine, Karen D]

Hi, Mark B.

After much education from the TSTT team, I learned that a "mesh instance" is
a database containing entities, adjacency info, sets, and tags.  It manages
all that stuff and answers queries about it.

A "mesh" is not really an ITAPS data type.  It is a concept defined by the
application.  The ITAPS "mesh instance" is organized only in terms of sets
of entities.  If the application considers a particular set of entities to
be a "mesh," that's great.  If an application wants to consider two
"meshes," it can load them into the same database and store them in separate
entity sets.  

So the short answer in the way I think about it is as follows:
A "mesh instance" is a database.
A "mesh" is an entity set in the database that the application interprets in
a particular way.

Your question is timely.  There is a discussion going on right now on the
tstt-interfaces mailing list about function names, including iMesh_newMesh.
In truth, it should be iMesh_newMeshInstance (or, as the discussion is
leading toward using "create" instead of "new", iMesh_createMeshInstance).

Karen
   


On 5/7/10 10:43 AM, "Mark Beall" <mbeall at simmetrix.com> wrote:

> Karen,
> 
> What you wrote brought up a question here that we haven't been able to
> answer cleanly. It's a pretty basic question that probably should have
> come up before, but it's possible that we have been assuming things
> based how we have interpreted what we have read, so here's the question:
> 
> What are the definitions of "mesh instance" and "mesh" for iMesh? More
> specifically, I can infer what the definition of a "mesh instance" is
> from the API and other documentation (although I think a precise
> definition would be nice), but it's not clear what the definition of a
> "mesh" is supposed to be.
> 
> Also, as a side question related to function naming, why is the
> function that creates a mesh instance named iMesh_newMesh?
> 
> mark
> 
> 
>> In a nutshell, we decided that a "mesh instance" is in effect a "mesh
>> database" that may contain one or more actual meshes.  As such, it
>> makes
>> most sense to have one database per implementation per process.
>> I apologize for not reviewing the mailing list and my notes before
>> the bootcamp.
>> 
>> [Off on a tangent:  A comment was made in the thread that the name
>> "mesh
>> instance" is confusing, as it implies an instantiation of a single
>> mesh,
>> and I still agree with that comment, preferring "mesh database."
>> But we are NOT arguing this point here, and I am NOT proposing to
>> change the name, so do NOT reply about this short vent.
>> There will be plenty more to reply about below.  :)]
> 
> 
> On May 4, 2010, at 11:07 AM, Devine, Karen D wrote:
> 
>> 
>> Attached is a write-up of the "compromise" solution I promised after
>> our
>> discussion at bootcamp.   I'm sorry it is late; I wrote it last week
>> but
>> forgot to mail it out.
>> 
>> Please read and consider it; then reply with your thoughts.  Thanks!
>> 
>> Karen
>> 
>> <compromise.txt>
> 
> 
>