[MOAB-dev] Getting ent set data when tag_size > 1

[Jed Brown]

On Sat, 17 Apr 2010 18:39:07 -0500, James Porter <jvporter at wisc.edu> wrote:
> This seems like the ideal way of handling time-dependent data, and
> having a storage order option would allow you to get the data back in
> blocked order, which would help maintain memory locality when you're
> iterating over timesteps as the outermost loop.

This is an "unlimited" dimension since you don't normally know the
number of steps a priori.  That interacts poorly with (internal)
interleaved storage.  Perhaps having "cheap duplicates" is a better way
to deal with this.  Also, what does the interface look like when the
mesh topology changes part way through the simulation?

I know that many of you disagree on this, but I think tags make sense
for metadata like definition of a function space, but not for the field
values themselves.  I think the interface will be fundamentally crippled
if the definition of fields is such that iMesh/iField/etc can make any
sense of these values.  It would have to accommodate fairly exotic
conforming and nonconforming spaces, mixed spaces, composite spaces,
spaces requiring reconstruction, and integral quantities.  I think the
only sane approach is to have the library components call back into user
code for the necessary evaluations.  Additionally, there is lots of
software that works with an algebraic representation of the problem.
Mesh association makes no sense, so these libraries will never have a
dependency on the mesh.  This is the context in which the solution is
actually produced, requiring users to tag the mesh with it is unnatural
because the mesh can't do anything with it so you would be creating a
dependency that has zero value.

Jed