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

[Jed Brown]

On Mon, 19 Apr 2010 10:11:25 -0500, Tim Tautges <tautges at mcs.anl.gov> wrote:
> By that argument, whether to use a library or custom code is a
> performance issue.  Of course it's more than that.

Of course, but if the library can't handle the discretization you want
to use, then you won't use the library regardless of it's performance.

> Using iMesh/MOAB as the native storage for these cases is probably not
> ideal, though the optimist in me wants to believe it's possible and
> that we can come close wrt performance.

It may be possible, but what does it offer that cannot be done while
keeping fields independent?

> You definitely want evaluations of this sort at least available based
> on the mesh, IMO; I'm not saying it has to be done that way only,
> though.

I'm not saying that the query won't reference the mesh (this is
necessary to avoid spatial searches), but I don't think that storing the
data on the mesh is desirable.  The query interface would reference mesh
entities, the user/discretization library would be responsible for
interpreting the tags on the relevant entities and indexing into
separate storage (this separate storage *could*, if the user chose, be a
tag corresponding to data stored on the mesh, but I think this level of
indirection is essential to decouple mesh from field operations).

> It's tough knowing how to present an interface that's both accessible,
> extensible, and high performing.

This is why library design is hard.

> I'm certain there are cases where this is true; I'm also certain there
> are cases when storing it with the mesh is right.

I'm curious what storing the field data on the mesh offers that can't be
done with one level of indirection.  I realize that nodal P1/Q1
discretizations are easy to work with on the mesh, but these can also be
stored by storing offsets on the mesh and field values separately (which
permits cheap field deconstruction and lets the states be stored in the
representation they are created), I'm not a fan of specializing for the
simple case.

> Actually I think a better way to look at this is needing more
> specialized interfaces, or at least segregation of functionality
> between interfaces.  Multiple interfaces may point to the same storage
> in their implementations, or may not (with performance differences in
> the former case).

It's not interoperable if you have M:N relations in the interface.
(Maybe I misunderstand you.)

Jed