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

[Tim Tautges]

Jed Brown wrote:
> 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.  

First off, the above is a typo, it should read "where storing and accessing *fields* through iMesh/MOAB".

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.

By that argument, whether to use a library or custom code is a performance issue.  Of course it's more than that.

> 
>>> 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.
> 

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.

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

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 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.

It's tough knowing how to present an interface that's both accessible, extensible, and high performing.  The ones I've 
seen have tended to be on either end of that spectrum, whereas I'm shooting for something more in between.

> 
>> 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.

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 wondering about the middle cases (and hoping we can explore that space a bit more in sisiphus).

> 
>> 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.
> 

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

- tim

> Jed
> 

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706