itaps-parallel copy information stored in iMesh

[Mark Miller]

Carl Ollivier-Gooch wrote:
> 
> One point of order here:  Mark, isn't a viz tool going to need to know
> where the copies of bdry entities are so that (for instance) a
> streamline can be continuous across parts?

Yes, in the case that a user is plotting streamlines, that information
could be useful. It depends on the streamline algorithm though. And,
more to the point, just because that information would be useful for
say a streamline algorithm, doesn't mean a viz. tool is going to want
it to be stored ALWAYS. 

In VisIt, we are supremely concerned with memory consumption to the
point that we try to 'patch up' a structured mesh whose structure has
been lost due to some kind of operation, like thresholding.

There is a big, big difference between memory requirements during
viz. and memory requirements during sim. An application may be holding
in memory as many as 100 different problem-sized arrays representing the
different physics variables it is computing. In this case, what is
the worry about having one more problem sized array? Not much. Likewise,
the additional memory of storing entity-copy information across part
boundaries is NOT likely to be a major concern. During viz. of that
same data, any given visual output will AT THE VERY MOST, maybe involve
1-10 problem sized arrays; a simple scalar field is just 1, a vector
field is 3, a tensor 6-9 and. In this case, the add'l memory a mesh
representing is forcing the viz. tool to use has much, much greater
impact.

So, in Viz. it is more important to be able to tune memory usage to
the operation(s) the user is actuall performing and not sort of pick
a storage scheme that will albeit enable all sorts of interesting
algorithms but wind up costing a lot for typical cases.

> 
> Even in that case, I agree that -ownership- is a concept that a viz tool
> won't care about (nor will anything else that doesn't modify the mesh).
>   Perhaps this is a situation where implementation could choose to
> accept a load-time argument that identifies the mesh database as
> read-only, and then optimize internally?  Not all implementations will
> take advantage of this savings, probably, but at least then they have
> the option to.

I think the notion of 'read-only' is a good one and I like the idea of
a client being able to make that 'promise' when it is interacting with
the data.

At the same time, I like an approach where I can tell iMeshP or whatever
to build up and destroy this information as I need it and then don't
need it. That is more flexible from the point of view of managing the
memory a client using iMeshP allocates.

But, I don't understand all the implications for the rest of the
interface.

Mark


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