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

Jed Brown jed at 59A2.org
Sat Apr 17 13:40:38 CDT 2010


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)
> * get/set functions that take in arrays of entity sets

Agree

> * get/set functions for arrays of entities/sets take a storage order

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

Jed

(I've mentioned it before, but iMesh_getDfltStorage should really return
iBase_INTERLEAVED because this is actually MOAB's native format and it
seems silly to advise users to use a suboptimal representation.)


More information about the moab-dev mailing list