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

[Tim Tautges]

Ting Xie wrote:
...

> 
> 1. Item #6
> 
>  -------------------------------------------
>  Replace two old functions:
>     FUNC_1 iMesh_getAllVtxCoords
>     FUNC_2 iMesh_getVtxCoordIndex
>  with one new function:
>     FUNC_3 iMesh_getAdjEntIndices
> 
>  -------------------------------------------
>  Functionality of these functions (abstracted from iMesh user-guide and
>  Jason's proposal):
> 
>    * FUNC_1 Gets the coordinates of the vertices contained in the entity set
>   as an array of doubles in the order specified by the user.
> 
>    * FUNC_2 Returns the indices of the vertices that define all entities of
>  a given type or topology in the mesh or entity set.
> 
>    * FUNC_3 Returns the indices of the adjacent entities of specified type,
>  for all  entities of a given type or topology in the mesh or entity set.
> 

Given the complexity of these functions, and the fact that they are of 
little help to the least complex situation and don't cover the most 
complex situation (see below), I'd vote for removing them entirely, 
maybe replacing them with a snippet of recommended code for doing 
typical things.  In other words, these are functions that IMO are 
redundant with little added value.

Explanation: assume that a minimal representation of a collection of 
mesh entities is the vertex positions and the connectivity of other 
entities.

Least complex: output the entire mesh
1. get all vertices (getEntities)
2. assign indexing & store in tags (setIntData)
3. get coords (getVtxCoords on list returned in 1)
4. get all other entities (getEntities)
5. get connectivity (getEntArrAdj on list returned in 4)
6. convert connectivity to indexed list (getIntData on list from 5)
7. get types/topologies (getEntArrTopo on list from 4)

That's calling 6 different functions, instead of 2 (getAllVtxCoords & 
getVtxCoordIndex).  On the surface, that seems like a reasonable 
savings.  However, if you consider a) a typical iMesh user will have 
already used the functions in 1-7 above, and won't have used these other 
2 functions, b) these other 2 functions are far from clear and easy to 
understand, and c) many users may already have work arrays they can use 
for values returned in 1-7 above, I'd assert that 1-7 is actually easier.

Most complex: output subset of mesh, specified as entities in a 
collection of sets

Ok, this is nowhere near most complex, but complex enough for my 
explanation.  To accomplish this, you need to:
- index the vertices used by entities in all the output sets
- get the handles of those vertices
- get the coordinates of those vertices
- for each block, get the entities and their topo and connectivity

The 2 functions, getAllVtxCoords and getVtxCoordIndex, are insufficient 
for this case, since the indexing will be wrong (i.e. there's not a 
single entity set containing all the entities being output from which an 
indexing can be derived).  Furthermore, as I read it, Jason's new 
function won't provide that functionality either, for the same reason.

- tim

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706