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

[Tim Tautges]

This is actually quite a relevant discussion, since a) iField discussions are underway and b) for other reasons I don't 
think time-dependent data is far off for MOAB (1-2 yrs).  So, clarifying questions and a few statements below.

Jed Brown wrote:
> 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'm keenly interested in what other apps do here.  I've asked mainly about file storage, and most apps seem to write a 
new file after topology changes.  I've not asked anybody who makes very frequent changes what they do.  There are 
multiple ways you could represent such things; the two that come to mind right away are masking entities for each time 
step, and backward-looking or forward-looking diffs.  Each has its pros and cons.  I'd be interested in hearing here 
what other codes do.

I'm going to parse the following pretty closely, since there are lots of issues:

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

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?)  For integral quantities, what are you integrating over? 
  If it corresponds to natural structures in the mesh, or structure you can annotate a mesh with (using sets), it 
can/should be stored there, IMO.

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.  I'm not sure this will ever be used as the basis for a 
high-performing application.  But, there are mesh-based evaluations which need to use e.g. integrals and point 
evaluations over typical finite element spaces, to support things like solution coupling.  Having those evaluations in a 
library would relieve the user from having to implement all that basic stuff, while allowing the implementation to do it 
more efficiently.


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.

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.  It may not make sense to put all the solution fields back on the mesh for all applications (i.e. to 
use the iMesh-based data for native field storage), because you know you'll be duplicating that storage when you 
construct the solver vectors for the unknowns.  But I think we at least need to support write back onto the mesh, for 
output and viz.  If you believe that, then I think it's a short distance to wanting operator evaluations also accessing 
the data on the mesh.

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.

- 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