Proposal for telling an implementation what adjacency info an app/service needs

[Jason Kraftcheck]

Carl Ollivier-Gooch wrote:
> One thing that's been discussed, and even openly experimented with is a 
> way to inform a mesh database of the actual adjacency information 
> required by an app/service.  (Also, which entity types need to be 
> iterable.)   This is how the swapping service communicates its adjacency 
> needs with MOAB, for instance.  FMDB's internal capabilities should 
> match up very well with this notion as well, allowing specialization 
> when appropriate.  Other implementations (GRUMMP, for instance) may or 
> may not be able to take much if any advantage of this, but that's no 
> reason not to allow an app/service to express what it actually needs.
> 
> The other possibility is to specify this at creation time, but if we're 
> going to do that, we should do the same with spatial dimension.  This 
> change provides the needed (?) capability in a way that's symmetric with 
> other calls.
> 
> Carl
> 
>     /**\brief  Tell an implementation the minimum adjacency information 
> required
>      *
>      * Tell an implementation the minimum adjacency information required
>      * by a service or application, in the form of an adjacency table.
>      * This table is a 4x4 array, with indices 0-based, where A(i,j)
>      * (i=row, j=column) is 1 if the service or application will require
>      * adjacencies between entities of dimension i to entities of
>      * dimension j and 0 otherwise.  A(i,i) is 1 if the service or
>      * application will iterate over entities of dimension i and 0
>      * otherwise.
>      * \param instance iMesh instance handle
>      * \param *adjacency_table Array representing adjacency table
>      *        required
>      * \param *err Pointer to error type returned from function
>      */
>   void iMesh_setAdjTable (iMesh_Instance instance,
>                           /*in*/ int* adjacency_table,
>                           /*out*/ int *err);

I don't think this is the correct way to do this.  The getAdjTable 
function returns the cost of making such queries.  It doesn't say 
anything about whether not, for a database such as MOAB that uses a 
reduced representation, that the requested entities are guaranteed to 
exist.  I assume that with your setAdjTable command you are trying to 
require that the database guarantee that lower-dimension entities exist 
explicitly that correspond to sides of higher-dimension entities. 
Otherwise I'm not sure what it means to set the adjacency table.

If my assumption is right, then the functionality you are requesting is 
not analogous to the getAdjTable function.  For example, with a reduced 
mesh database it is common for meshing applications to define the quads 
corresponding to sides of hexahedra only on the skin of a hex mesh.  The 
getAdjTable results give some indication of how quickly the database can 
find whether or not such quads exist for a given hex and return the ones 
that due.  It says nothing about whether or not you'll get six quads for 
a given hex.

- jason