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

[Tim Tautges]

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

Well, maybe one is trying out different discretization schemes before settling on one (not that I'm asserting MOAB would 
be the best place to do that).

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

Support for parallel IO (eventually, doesn't work well now), viz, handling of metadata associated with the mesh, etc.

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

That kind of indirection has to be possible, but I'm asserting others also need to be possible.

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

Some people are very sensitive to library dependencies, and you want to be careful about introducing ones that may not 
be absolutely necessary.  That excuse is abused more often than it's valid, so that only takes me so far.  A more 
concrete example is point location in a mesh, which depends on the shape functions.  You're certainly going to store the 
vertex locations with the mesh; whatever library you use for field evaluation should be able to evaluate those directly 
from the mesh.  From there it's a short way to interpolating solution fields, for coupling.

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

You definitely need to be careful about too many interfaces.

- 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