itaps-parallel [Fwd: Re: iMesh_getVtxCoordIndex and iMesh_getEntities]

[Lori A. Diachin]

One item I would like to at least briefly discuss on today's telecon is 
the proposal that Jason makes below.  It seems as though there is a lot 
of confusion regarding the getVtxCoordIndex call and I'd like to discuss 
if this solution makes sense...

-------- Original Message --------
Subject: 	Re: iMesh_getVtxCoordIndex and iMesh_getEntities
Date: 	Fri, 17 Oct 2008 12:13:31 -0500
From: 	Jason Kraftcheck <kraftche at cae.wisc.edu>
To: 	tstt-interface <tstt-interface at mcs.anl.gov>
References: 	<48F8C3EC.6010506 at cae.wisc.edu>



Jason Kraftcheck wrote:
> iMesh_getVtxCoordIndex specifies that it returns indices into the array of
> vertex handles that would be returned by iMesh_getEntities (presumably
> called with entity_type == iBase_VERTEX).   This seems like a fairly
> straightforward mechanism to build/access global arrays of entities when the
> entity_set_handle for both calls is the root set.  But what is the behavior
> when it is not the root set?  If I pass some non-root set handle to
> iMesh_getVtxCoordIdx, it returns indices into the data from a hypothetical
> call to iMesh_getEntities with what as its set handle?  The same set?  The
> root set?  If it is not the root set, then what happens a vertex in the
> connectivity of some entity in the iMesh_getVtxCoordIdx would not be in the
> results of a call to iMesh_getEntities?
> 
> Also, naming this function "iMesh_getVtxCoordIdx" is somewhat misleading.  I
> had at first assumed that it was returning indices into the results of
> iMesh_getAllVtxCoords.  Shouldn't it be something like "iMesh_getVtxHandleIdx"?
> 

Apologies for replying to my own message.

After thinking about this a bit more, I think this dichotomy of a single
operation is confusing and of dubious value.  For any case other than a very
simplistic mesh database that had a single array of vertices with no holes
for which these functions are called with the root set, the call to
iMesh_getVtxCoordIdx will have to do the equivalent of the iMesh_getEntities
call to determine the correct indices.  So all the dichotomy seems to
accomplish is that the internal work of the iMesh_getEntities call has to be
done twice.  If the goal is to have a single array of unique vertex handles
and the connectivity of some elements specified as indices into that array,
it would have been better to have a slightly more complex version of
getAdjEntities that returned precisely that:

  void iMesh_getAdjEntIndices(iMesh_Instance instance,
                          /*in*/ const iBase_EntityHandle entity_set_handle,
                          /*in*/ const int entity_type_requestor,
                          /*in*/ const int entity_topology_requestor,
                          /*in*/ const int entity_type_requested,
                          /*inout*/ iBase_EntityHandle** adj_entity_handles,
                          /*inout*/ int* adj_entity_handles_allocated,
                          /*out*/ int* adj_entity_handles_size,
                --->      /*inout*/ iBsae_EntityHandle** adj_entity_indices,
                --->      /*inout*/ int* adj_entity_indices_allocated,
                --->      /*out*/ int* adj_entity_indices_size,
                          /*inout*/ int** offset,
                          /*inout*/ int* offset_allocated,
                          /*out*/ int* offset_size,
                          /*inout*/ int** in_entity_set,
                          /*inout*/ int* in_entity_set_allocated,
                          /*out*/ int* in_entity_set_size,
                          /*out*/ int *err);



Apologies for questioning the iMesh interface at this late date.  I haven't
looked much at some of these functions before trying to implement the iMeshP
versions of them.

- jason