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

[Jed Brown]

On Sun, 18 Apr 2010 10:50:14 -0500, Tim Tautges <tautges at mcs.anl.gov> wrote:
> > 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.
> 
> Well, this seems a bit overly strong.  We need something where the
> simple things are simple, and the complicated things are possible (to
> quote Jason, among others).  I think there are cases where storing and
> accessing the mesh through iMesh/MOAB would be a good idea, and others
> where it wouldn't.  I'm making some important assumptions here,
> though: a) iMesh is changed to support dense tags more directly (an
> extension that does this is in the pipe), b) there's a mechanism for
> accessing tag values with a "sequence number", which is really a time
> stamp with arbitrary time value (with actual time values obtained from
> another tag, probably), c) it's possible to access tag data through a
> pointer to actual tag storage (and a way to iterate over subranges
> with contiguous tag storage).  I have my doubts whether anybody else's
> implementation of iMesh will be able to handle this; doing it as an
> iMesh extension buys me Fortran (and Python) access.

These are all essentially performance issues.  I'm concerned with the
discretization itself.

> > It would have to accommodate fairly exotic conforming and
> > nonconforming spaces, mixed spaces, composite spaces, spaces
> > requiring reconstruction, and integral quantities.
> 
> Some of these characteristics are reflected in the mesh structure,
> e.g. for nonconforming meshes (probably not nearly as general as
> nonconforming spaces, right?  or totally unrelated?)

I was thinking of finite element spaces with less than C^0 regularity
even on conforming meshes.  The lowest order versions of these spaces
usually have matching face averages between elements, higher order
versions have more involved inter-element consistency requirements, but
do not reduce to agreement at edge nodes (sometimes the number of
constraints per element is different from the number of boundary nodes).
The basis funtions may also be modified by material properties, there
are lots of different ways that this is done, but most of them would be
covered if you had something that worked for XFEM.

> For integral quantities, what are you integrating over?

Regions/surfaces in the domain perhaps delineated by markers
(e.g. particles or level sets), possibly other dimensions (like
distribution spaces).

> > I think the only sane approach is to have the library components
> > call back into user code for the necessary evaluations.
> 
> For more exotic stuff, yes; so, that should be a supported capability.
> For the more standard types of evaluations, I'd assert we want to
> support those in the library itself.

If you have a different interface for this case then there is a high
probability that it just won't work for the "hard case".  There is also
the isse of making transition from the "easy" to "hard" scenario as easy
as possible.  I prefer writing the interface for the hard case and then
providing a library of "default evaluators" or whatever for the user to
use when their discretization is "easy".  If this library is extensible,
then you can eventually build up implementations for the more exotic
cases, and the implementations serve as a starting point for the user
transitioning to a more complex discretization.

> So that's the rub, I think.  The solution is computed in terms of the
> algebraic structures, but stored and visualized in terms of the mesh.

My point is that storing it on the mesh is a limiting thing that I think
is not really desirable.  Querying values in terms of the mesh is
necessary (calling into user or discretization library code), but
defining it in terms of the mesh is likely to either be very awkward or
lose information.

> Finally, there are many other situations where iField will need to get
> field data in other ways, e.g. experimental or observed data and
> analytical functions (and callbacks too).  So, iMesh-derived field
> data absolutely cannot be the only way this data is retrieved; by the
> same token, I think it must be one of the ways that's supported.

You can put the data wherever you want as long as there isn't a special
interface to handle mesh-oriented fields versus something more general.

Jed