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

[James Porter]

On Sat, 2010-04-17 at 17:20 -0500, Tim Tautges wrote:
> 
> Jed Brown wrote:
> > On Fri, 16 Apr 2010 15:27:36 -0500, James Porter <jvporter at wisc.edu> wrote:
> >> On Tue, 2010-04-13 at 13:34 -0500, Tim Tautges wrote:
> >>> Jed Brown wrote:
> >>>> There ought to be get/setEntSetArrData (in fact, I would only expose the
> >>>> array interface because the single-tag versions are crippled and not
> >>>> more usable). 
> >>> Agreed.  I'll put that on the list of extensions to write, and will propose it to itaps (nobody else really uses sets in 
> >>> any serious way, so that's probably why it hasn't come up there).
> >> Attached is what I personally would like to see in terms of interface.  
> >>
> >> Main points:
> >> * No type-specific functions (uses void* everywhere)
> 
> I know already this one won't fly (I opposed it when first proposed, and lost).

I think it makes sense to have "standard" type-specific helper
functions, but I see that as something that sits on top of iMesh, not as
a part of the iMesh spec itself. Something like iMesh_helpers that could
be available from the ITAPS page. The C version could pretty easily be
handled as macros; not sure about Fortran. (Though I think that trying
to maintain compatibility with both C and Fortran hurts the quality of
the interface anyway, like with the string arguments.)

> > Why is this necessary?  It seems to me that BLOCKED may as well be
> > different tags.  Coordinates are special because they have additional
> > meaning and legacy codes/file formats made a suboptimal choice about
> > storage.  I'd rather not see this complicate the interface and
> > presumably there aren't legacy codes using tags with BLOCKED storage
> > (since it's not currently available) and it doesn't make sense to write
> > a new code with BLOCKED (ITAPS won't perform well on classic vector
> > machines anyway).
> 
> I doubt many apps use multi-valued, typed, tags, and those few that do aren't overly burdened by having just interleaved 
> versions.

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.

It would also be useful for what actually prompted this whole
discussion: setting tags for extrude sets in MeshKit. With copy sets, we
create a single-value tag that relates source entities to their copied
targets. For extrude sets, we could create a multi-value tag that points
to all the extruded targets (one per layer). The way I'm doing it now,
I'd probably set the tag in blocked order and get the tag in interleaved
order.

- Jim