itaps-parallel [Fwd: **** iMesh.h and iBase.h changes ****]

[Jason Kraftcheck]

Ting Xie wrote:
> Hi Jason,
> 
> We still do not know what are indices of adjacent entities in the new
> proposed function. Thus we make a simple example to demonstrate the
> problem, and try to clarify what are the inputs and outputs. Please
> correct me if you find any mistakes. Thanks.
> 

See below.

> The attached is a simple mesh picture of two adjacent hexes. We call
> iMesh_getAdjEntIndices to get two following requests.
> 
>  1. To get adjacent edge indices for the hexes
> 
>   INPUT: type=region, topo=hex, adj_type=edge
>   OUTPUT:
>     hex_handles: H1, H2
>     adj_edge_handles: e1, e2, ..., e12, e1', e2', ..., e12'

The above is not correct.  The hexes will share some edges, so the resulting
list would presumably contain 20 rather than 24 edges.

>     adj_indices: 1, ..., 12, 1', 2', ..., 12'

That is not correct.  Why would we return the same sequence of 1...offset[i]
for each element?  All values in this list are indices into
adj_edge_handles.  16 of the values in the range [0..19] will occur exactly
once.  4 will occur twice, for the 4 edges that are shared by both hexes.


>     offset: 0, 12, 24
> 
>  2. To get adjacent vertex indices for the hexes
> 
>  INPUT: type=region, topo=hex, adj_type=vertex
>  OUTPUT:
>     hex_handles: H1, H2
>     adj_edge_handles: v1, v2, ..., v8, v1', v2', ..., v8'

Again, this list will not contain any duplicates.  If the two hexes share
two vertices, the handle for that shared vertex will occur exactly *once* in
the list.

>     adj_indices: 1, ..., 8, 1', 2', ..., 8'

This is wrong, too.  Perhaps you are confused by the mistake where
adj_indices is declared to be of type iBase_EntityHandle** when it should be
int**.


>     offset: 0, 8, 16
> 



> 
> Since we do not know what are adj_indices. We guess that it has two options:
> 
>   (1) 1,..., 8
> (The order of adjacent edges local to the hex, should that start from 0 or
> 1? If this is the case, we do not have any problem. )
> 
>   (2) the unique integer ids of the edges in the mesh
> (If mesh database has dynamic storage because of mesh modification, like
> FMDB, and it does not store the unique ids for entities, what should
> return in the adj_indices array? )
> 

It is neither of these.  In your second example adj_edge_handles contains
all the vertices that are in either of the two hexes, without duplicates.
adj_indices contains 8 values for each hex.  For each of the 8 vertices
adjacent to the hex, the value in adj_indices in the index into
adj_edge_handles where the handle for the corresponding vertex is stored.

The comment from the original source was:
   *\param adj_entity_indices    For each entity in 'entity_handles', the
   *                             adjacent entities of type
   *                             'entity_type_requested', specified as
   *                             indices into 'adj_entity_handles'.  The
   *                             values are concatenated into a single
   *                             array in the order of the entity handles
   *                             in 'entity_handles'.


- jason