itaps-parallel [Fwd: **** iMesh.h and iBase.h changes ****]
Ting Xie
txie at scorec.rpi.edu
Sun Jan 18 23:41:55 CST 2009
Hi all,
Our (RPI team) concerns on the iMesh.h and iBase.h changes are listed as
follows. Please let us know if you have any questions. Thanks.
--------------------------------------------------
We sort the item number in Jason's proposal in the order of priority. The
function with the higher priority means that we have more confusion and it
might need more effort in the implementation.
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.
-------------------------------------------
OUR CONCERNS:
*** 1.1 FUNC_3 does not return the vertex coordinates, i.e., it can not
replace FUNC_1.
To get the coordinates for vertex array returned from FUNC_3, we still
have to call iMesh_getVtxArrCoords function. This was already indicated
in the example in Jason's proposal.
>>> The same code in the new API will be:
>>> iMesh_getAdjEntIndices( instance, root_set, ......
>>> iMesh_getVtxArrCoords( instance, .....
But iMesh_getVtxCoords can not replace FUNC_1 either. Because it only
gets the coordinates for an array of vertices, which is not
entity_set_handle. To get the coordinates of all the vertices in the
entity_set through iMesh_getVtxCoords, we have to call
iMesh_getEntities first, which needs extra work (iterate all vertices
in the entity_set).
One good thing: if we call iMesh_getVtxArrCoords, and use vertex array
returned from FUNC_3 as the input, the problem size is reduced.
*** 1.2 FUNC_3 can return the indices for adjacent entities of any type,
not only verices.
This increases the flexibility of FUNC_3. But do we need that? Does the
adjacency index important for other topological entity type? Or most of
the time the applications just want to obtain the adjacent entities. If
that is the case, we can use iMesh_getAdjEntities instead of FUNC_3.
Even if we want to get the adjacency indices, the indicies defined in
those functions (both old version and new verion) are still not clear.
Are
these functions based on the assumption that each mesh entity,
particular vertex, has an unique integer id. This assumption might not
be true or right, especially in larger mesh cases.
*** 1.3 Jason's proposal used a simple hex mesh to claim the advantages
of FUNC_3, but the real applications can be much more complex,
especially for mixed topological mesh and non-manifold meshes.
Considering all kinds of situations added from the flexibility, the
implementation of FUNC_3 will be much more complex.
*** 1.4 Compare the argument lists of FUNC_3 and iMesh_getAdjEntities:
FUNC_3 returns both entity_handles of requested type/topo and
adj_entity_handles of specified type, while FUNC_2 does not.
The extra outputs eliminate a lot of unnecessary extra work within the
implementations. But this might be a problem if application does not
want to get entity_handles and adj_entity_handles info. And the outputs
will take a lot of memory, especially when the two arrays are huge.
*** 1.5 FUNC_1 and FUNC_2 are coupled together. The coordinate index
from FUNC_2 depends on the order of the vertex coordinates being
returned from FUNC_1 (indicated in iMesh user-guide).
One reason to introduce FUNC_3 is to eliminate the coupling. But in
fact, the index order from FUNC_3 should be consistent with the entity
order returned from iMesh_getEntities.
*** 1.6 entity_topologies argument is not provided in FUNC_3, as that in
FUNC_2.
This is a minor problem. And yes, we can use iMesh_getEntArrTopo to get
the info, as Jason mentioned.
---------------------------------------------
2. Item #4
It is not clear about what is the definition about vertex geometric
dimension.
For example, a surface mesh which only has mesh faces, edges and
vertices, the coordinates of the vertices can have (x, y, z) (curved
surfaces). In such case, what's right vertex dimension size, 2 or 3?
3. Item #8
It is not clear about how to replace iBase_EntityHandle with
iBase_EntitySetHandle where appropriate.
4. Item #5
This is a little confused. Yes, the value of the entity_set_handle
(the pointer itself) is not changed. But the content of the entity_set
(the value it points to) is changed (because of the remove/add
operation).
5. Item #7
New function: iMesh_isEntArrContained, raised from Item #6. It is an
array version for iMesh_isEntContained.
6. Item #1 - #3
Agree without any problem.
---------------------------------------------
Ting
> Hi All,
>
> I'd like to check in on the status of everyone's changes wrt to the
> iMesh.h and iBase.h files that Jason sent out back in October. We
> decided to defer these until after SC08 and gave ourselves an internal
> deadline of Dec 15... so, are we done yet? :-)
>
> Seriously - it was my understanding that folks had agreed in principle
> to all of these changes; the one exception was what to do about item #6
> below. It may very well be that we need a quick telecon to discuss
> this as well as get an update on status. Carl is planning to send out
> the iMesh paper by Jan 23, so we may want to touch base before then..
> when are folks available for a telecon? To narrow it down a bit, please
> send me the times you are not available on Monday/Tuesday Jan 12th and
> 13th, or Tues/Wed the 20th and 21st.
>
> Thanks,
> Lori
>
> -------- Original Message --------
> Subject: **** iMesh.h and iBase.h changes ****
> Date: Fri, 24 Oct 2008 18:13:11 -0500
> From: Jason Kraftcheck <kraftche at cae.wisc.edu>
> To: TSTT Interface <tstt-interface at mcs.anl.gov>
>
>
>
> Here is the list of proposed changes to iMesh.h (yes, not just iMeshP.h)
> that were a) agreed upon during the latest telecon and b) may need to be
> completed by all implementations by SC'08. If you object to any of this,
> please speak out soon. I've attached copies of the interface definitions,
> updated as described below.
>
>
> 1) Version defines: Beginning with version 0.8 of iMesh.h, we will add
> the
> following C preprocessor macros. This will allow, going forward,
> applications to be compatible with more than one version of the
> interface*.
> #define IMESH_MAJOR_VERSION 0
> #define IMESH_MINOR_VERSION 7
>
> 2) Zero set handle: All mention of passing 'zero' for a set handle in all
> iMesh.h documention should be replaced with the root set handle*.
> Implementations for which a) the root set handle is not zero and b) that
> actually followed the documentation in that they check for zero rather
> than
> the root set will need to be updated.
>
> 3) Handle types*: The current handle definitions:
> typedef void* iBase_Instance;
> typedef void* iBase_EntityHandle;
> typedef void* iBase_EntitySetHandle;
> typedef void* iBase_TagHandle;
>
> typedef void* iMesh_Instance;
> typedef void* iMesh_EntityIterator;
> typedef void* iMesh_EntityArrIterator;
> will be replaced with:
> typedef struct iBase_Instance_Private* iBase_Instance;
> typedef struct iBase_EntityHandle_Private* iBase_EntityHandle;
> typedef struct iBase_EntitySetHandle_Private* iBase_EntitySetHandle;
> typedef struct iBase_TagHandle_Private* iBase_TagHandle;
>
> typedef struct iMesh_Instance_Private* iMesh_Instance;
> typedef struct iMesh_EntityIterator_Private* iMesh_EntityIterator;
> typedef struct iMesh_EntityArrIterator_Private* iMesh_EntityArrIterator;
>
>
> 4) New Function:
> /**\brief Set geometric dimension of vertex coordinates
> *
> * Set the geometric dimension of the mesh. Notes: An application
> * should not expect this function to succeed unless the mesh database
> * is empty (no vertices created, no files read, etc.)
> *\param instance Mesh database from which to request change.
> *\param geom_dim Requested geometric dimension.
> */
> void iMesh_setGeometricDimension( iMesh_Intance instance,
> /*in*/ int geom_dim,
> /*out*/ int* err );
>
>
> 5) Changed Functions: There are several functions for which an entity set
> handle is treated as 'inout' where it should be 'in'*. These include:
> iMesh_addEntToSet
> iMesh_rmvEntFromSet
> iMesh_addEntArrToSet
> iMesh_rmvEntArrFromSet
> iMesh_addEntSet
> iMesh_rmvEntSet
> iMesh_addPrntChld
> iMesh_rmvPrntChld
> The argument shoudl be 'in' because the argument (the value of the
> handle) is not changed.
> NOTE: The changes described in 3) will ensure that this change results
> in compile-time errors. Without the changes in 3), changing the real
> type from void** to void* for the arguments would still compile,
> which could be disastrous.
>
> 6) The following two functions:
> iMesh_getAllVtxCoords
> iMesh_getVtxCoordIndex
> will be replaced with the new function below.
> NOTE: This is slightly different than what was discussed during
> the telecon. I a) noticed a deficiency in the usage (added
> the 'entity_handles' output list) and b) dropped the in_entity_set
> argument, for which no agreement was reached during the telecon.
>
> /**\brief Get indexed representation of mesh or subset of mesh
> *
> * Given an entity set and optionally a type or topology, return:
> * - The entities in the set of the specified type or topology
> * - The entities adjacent to those entities with a specified
> * type, as a list of unique handles.
> * - For each entity in the first list, the adjacent entities,
> * specified as indices into the second list.
> *
> *\param entity_set_handle The set of entities from which to query
> *\param entity_type_requestor If not iBase_ALL_TYPES, act only on
> * the subset of 'entity_set_handle' of the
> * specified type.
> *\param entity_topology_requestor If not iMesh_ALL_TOPOLOGIES, act
> only
> * on the subset of 'entity_set_handle'
> with
> * the specified topology.
> *\param entity_type_requested The type of the adjacent entities to
> * return.
> *\param entity_handles The handles of the (non-struct) subset
> of
> * the entity set indicated by
> * 'entity_set_handle' and the optional
> type
> * and topology filtering arguments.
> *\param adj_entity_handles The union of the entities of type
> * 'requested_entity_type' adjacent to each
> * entity in 'entity_handles'.
> *\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'.
> *\param offset For each entity in the corresponding
> * position in 'entity_handles', the
> position
> * in 'adj_entity_indices' at which values
> * for that entity are stored.
> */
> 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** entity_handles,
> /*inout*/ int* entity_handles_allocated,
> /*out*/ int* entity_handles_size,
> /*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,
> /*out*/ int *err);
>
> The code below uses the old interface to retrieve a copy of a hexahedral
> mesh in a simple array form:
> MBEntityHandle *vertices = 0, *hexes = 0;
> int *hex_vertex_indices = 0, *hex_vertex_offsets = 0;
> double* coords;
> int num_vertices, num_hexes, junk, junk2, junk3, err, order;
> int *junk_array;
> junk = 0;
> iMesh_getEntities( instance, root_set,
> iBase_ALL_TYPES,
> iMesh_HEXAHEDRON,
> &hexes, &junk, &num_hexes, &err );
> junk = 0;
> iMesh_getEntities( instance, root_set,
> iBase_VERTEX,
> iMesh_ALL_TOPOLOGIES,
> &vertices, &junk, &num_vertices, &err );
> junk = junk2 = 0;
> junk_array = NULL;
> order = iBase_INTERLEAVED;
> iMesh_getAllVtxCoords( instance, root_set,
> &coords, &junk, &junk,
> &junk_array, &junk2, &junk2,
> &order, &err);
> free(junk_array);
> junk = junk2 = junk3 = 0;
> junk_array = NULL;
> iMesh_getVtxCoordIndex( instance, root_set,
> iBase_ALL_TYPES, iMesh_HEXAHEDRON,
> iBase_VERTEX,
> &hex_vertex_offsets, &junk, &junk,
> &hex_vertex_indices, &junk2, &junk2,
> &junk_array, &junk3, &junk3,
> &err );
> free( junk_array );
>
> The same code in the new API will be:
> MBEntityHandle *vertices = 0, *hexes = 0;
> int *hex_vertex_indices = 0, *hex_vertex_offsets = 0;
> double* coords;
> int num_vertices, num_hexes, junk, junk2, junk3, junk4, err;
> int order;
> junk = junk2 = junk3 = junk4 = 0;
> iMesh_getAdjEntIndices( instance, root_set,
> iBase_ALL_TYPES, iMesh_HEXAHEDRON,
> iBase_VERTEX,
> &hexes, &junk, &num_hexes,
> &vertices, &junk2, &num_vertices,
> &hex_vertex_indices, &junk3, &junk3,
> &hex_vertex_offsets, &junk4, &junk4 );
> junk = 0;
> order = iBase_INTERLEAVED;
> iMesh_getVtxArrCoords( instance,
> vertices, num_vertex,
> &order,
> &coords, &junk, &junk,
> &err );
>
> 7) New Function: Array form of iMesh_isEntContained to replace
> containment flags no longer returned from iMesh_getVtxCoordIndex
> (and hopefully some day all the other functions with a similar
> argument).
>
> void iMesh_isEntArrContained( iMesh_Instance instance,
> /*in*/ iBase_EntitySetHandle containing_set,
> /*in*/ const iBase_EntityHandle* entity_handles,
> /*in*/ int num_entity_handles,
> /*inout*/ int** is_contained,
> /*inout*/ int* is_contained_allocated,
> /*out*/ int* is_contained_size,
> /*out*/ int* err );
>
>
> 8) Replace some iBase_EntityHandle with iBase_EntitySetHandle where
> appropriate*:
> iMesh_getAdjEntIndices
> iMesh_getAdjEntities
>
> - jason
>
>
> * Similar changes should probably be made to iGeom.h, iMeshP.h, and
> iRel.h,
> but that was not discussed during the telecon.
>
>
>
>
More information about the itaps-parallel
mailing list