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

[Carl Ollivier-Gooch]

Jason Kraftcheck wrote:
> 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.

Okay, so maybe the calls aren't analogous and the name should be 
changed, but you're right about the functionality I'm proposing.  In 
addition, the diagonal elements of the input would request that 
particular entity types be iterable.  Yes, that probably means the 
implementation will have to store them explicitly, but if a client needs 
to iterate over them, it needs to, and letting an implementation with 
flexibility in what it stores what will actually be needed can surely be 
exploited...

Carl

-- 
------------------------------------------------------------------------
Dr. Carl Ollivier-Gooch, P.Eng.                   Voice: +1-604-822-1854
Associate Professor                                 Fax: +1-604-822-2403
Department of Mechanical Engineering             email: cfog at mech.ubc.ca
University of British Columbia              http://www.mech.ubc.ca/~cfog
Vancouver, BC  V6T 1Z4                  http://tetra.mech.ubc.ca/ANSLab/
------------------------------------------------------------------------