Index: DraftInterface.h =================================================================== RCS file: /space/CVS-Zoltan/ITAPS/Documents/ParallelInterface/DraftInterface.h,v retrieving revision 1.2 retrieving revision 1.7 diff -r1.2 -r1.7 29c29,30 < - "Local" operations are operations performed with respect to a part. --- > - "Local" operations are operations performed with respect to a part or > a mesh instance within a process. 43,46d43 < Partition instances know which mesh instance's entities they partition. < KDD: I DOUBT WE NEED THIS KNOWLEDGE ANYMORE. < KDD: PERHAPS WE SHOULD NOT MAKE IT A REQUIREMENT BUT, RATHER, AN < KDD: IMPLEMENTATION OPTION. 48c45 < Mesh instances know which partitions they are in. --- > Mesh instances know which partitions they contain. 49a47,81 > Part IDs are valid globally; part handles are local to a process. > Part IDs are NOT assumed to be consecutive; nor are they assumed to be > in the range [0:numParts-1]. Thus, processes can generate new Part IDs > without communication with other processes. > TODO: AN IMPLEMENTATION IDEA (BUT NOT A REQUIREMENT) FOR PART IDS FROM CARL: > TODO: Using n bits for process rank, > TODO: m bits for local ID would create part ID's that were easy > TODO: to create and interpret... with cleverness, we could work things so > TODO: that n+m <= 31 (a billion part ID's...) so that this all looks like an > TODO: int, and we don't have to mess with the sign bit. > > TODO: In not assuming the range [0:numParts-1] for part IDs, we give up > TODO: the easy ability to use part IDs as indices (as, for example, Onkar > TODO: did in his Entity Level comments of Feb 5). > > TODO: SHOULD PART IDS BE OF TYPE prefix_PartID_type? Which leads me to > TODO: my next question.... > > TODO: ARE PART IDS REALLY REMOTE PART HANDLES, THEN? SHOULD WE MAKE A > TODO: DISTINCTION BETWEEN PART IDS AND PART HANDLES? THE INTEGER VALUES > TODO: HAD VALUE IF THEY COULD BE USED AS ARRAY INDICES, BUT SINCE THEY > TODO: CANNOT, PERHAPS WE SHOULD JUST CALL THEM REMOTE PART HANDLES AND > TODO: REMOVE THE DISTINCTION BETWEEN IDS AND HANDLES. WE COULD THEN > TODO: REMOVE FUNCTIONS MAPPING BETWEEN IDS AND HANDLES, BUT WE WOULD > TODO: PROBABLY NEED TO ADD A TEST FOR WHETHER A PART HANDLE WAS REMOTE > TODO: OR LOCAL. > > > - TODO: LORI OBSERVES: IN MANY FUNCTIONS THERE'S A "getNumX" AND A "getX". > TODO: WE SHOULD LOOK AT WHETHER OR NOT WE ALWAYS NEED BOTH FUNCTIONS > TODO: OR IF WE CAN JUST USE getX, WHICH RETURNS THE NUM AS A BYPRODUCT. > TODO: I REALIZE THERE ARE MANY CASES WHERE YOU DO NEED TO SEPARATE THE > TODO: CALLS, BUT PERHAPS NOT ALL. > TODO: KDD ADDS: WHAT IS THE CONVENTION FOR getNumX AND getX IN ITAPS? > TODO: PROVIDING getNumX ALLOWS THE APPLICATION TO PREALLOCATE MEMORY. 51c83,86 < Assumptions that aren't currently causing heartburn: --- > > - TODO: NEED TO DECIDE WHICH FUNCTIONS NEED both getX AND getXArr VERSIONS. > > Assumptions: 54,58c89,92 < - Many iMesh functions that accept a mesh instance and an EntitySet handle < are also useful in the context of partition handles and part handles. < These functions will be reinterpreted so that they can accept either a < mesh instance and EntitySet handle, or a partition handle and a < part handle. See Carl's Oct 15 email for more detail. --- > - Many iMesh functions that accept EntitySet handles > are also useful in the context of part handles. > These functions will be reinterpreted so that they can accept either an > EntitySet handle, or a part handle. See Carl's Oct 15 email for more detail. 61,65c95,104 < - For **each item** of functionality in this document, there will be a < function (or set of functions) to provide the functionality. The < implementation can decide whether these functions should be simple < wrappers over existing data model functionality or more intrusive functions < in the implementation. --- > Generation and management of global IDs will be provided as a service > above the parallel iMesh interface. > Operations to manage global IDs of entities that are partitioned include > set/retrieve global IDs; generate global IDs; > set/retrieve global ID size; map between entities and global IDs; > compare global IDs. > Since there was little disagreement with > Vitus'/Karen's document on global IDs, we will use it in the first > draft with modifications to associate the "global" nature of the > IDs with partitions. 75,76c114,115 < // Create a partition handle: Given a mesh instance to be < // included in the partition and a communicator, return a partition --- > // Create a partition handle: Given a mesh instance to contain > // the partition and a communicator, return a partition 79a119,124 > // For serial use, *communicator may be MPI_COMM_SELF or communicator may > // be NULL. > // TODO: May still revise this function to make it less MPI specific. > // TODO: Don't want to require applications to link with MPI if the > // TODO: implementation doesn't require it. > // TODO: May define an ITAPS_Comm name typedef'ed appropriately. 82c127 < /*in*/ MPI_Comm communicator, --- > /*in*/ MPI_Comm *communicator, 94a140,152 > // Update a partition after parts have been added. > // Gives the implementation an opportunity to locally store info > // about the partition so that queries on the partition can be > // performed without synchronous communication. > // TODO: Determine which values must be updated to allow other > // TODO: interface functions to be performed without synchronous > // TODO: communication. > > void prefix_updatePartitionPar(iMesh_Instance instance, > prefix_PartitionHandle partition_handle, > int *err); > > //////////////////////////////// 102,107d159 < // Given a partition handle, return the mesh instance that is < // included in the partition. < // KDD: DO WE NEED THIS CAPABILITY? IT IS HARD TO SPECIFY < // KDD: IF iMesh_Instance MUST ALWAYS BE FIRST ARG OF iMesh FUNCTIONS. :) < < //////////////////////////////// 123a176,177 > // TODO: Can this function be made local (through updates from > // TODO: prefix_updatePartitionPar)? 133a188,189 > // TODO: Are these functions required to be local (through updates from > // TODO: prefix_updatePartitionPar)? 135c191 < void prefix_getRank(iMesh_Instance instance, --- > void prefix_getPartRank(iMesh_Instance instance, 140c196 < void prefix_getRankArr(iMesh_Instance instance, --- > void prefix_getPartRankArr(iMesh_Instance instance, 151c207 < // + Given a partition handle and an process rank, --- > // + Given a partition handle and a process rank, 152a209,210 > // TODO: Are these functions required to be local (through updates from > // TODO: prefix_updatePartitionPar)? 154c212 < void prefix_getNumPartIds(iMesh_Instance instance, --- > void prefix_getNumParts(iMesh_Instance instance, 157c215 < /*out*/ int *num_pids, --- > /*out*/ int *num_parts, 160c218 < void prefix_getNumPartIdsArr(iMesh_Instance instance, --- > void prefix_getNumPartsArr(iMesh_Instance instance, 164,165c222,223 < /*inout*/ int **num_pids, < /*inout*/ int *num_pids_allocated, --- > /*inout*/ int **num_parts, > /*inout*/ int *num_parts_allocated, 169a228,229 > // TODO: Are these functions required to be local (through updates from > // TODO: prefix_updatePartitionPar)? 171c231 < void prefix_getPartIdsFromRank(iMesh_Instance instance, --- > void prefix_getPartIds(iMesh_Instance instance, 179c239 < void prefix_getPartIdsFromRankArr(iMesh_Instance instance, --- > void prefix_getPartIdsArr(iMesh_Instance instance, 189,206d248 < // Map from the process rank to part handles. < // + Given a partition handle, return the number of on-process parts in the < // partition. < < void prefix_getNumParts(iMesh_Instance instance, < const prefix_PartitionHandle partition_handle, < int *num_part, < int *err); < < // + Given a partition handle, return all on-process part handles in the < // partition. < < void prefix_getParts(iMesh_Instance instance, < const prefix_PartitionHandle partition_handle, < prefix_PartHandle *part_handles, < int *err); < < //////////////////////////////// 211a254,262 > // TODO: TIM ASKS: DOES IT MAKE SENSE TO HAVE AN ENTITY SET HANDLE PARAMEMTER > // TODO: IN THESE FUNCTIONS? DO ENTITY SETS GIVEN ON EACH PROCESS HAVE TO BE > // TODO: ONES SHARED IN PARALLEL? > // TODO: KDD SAYS: YES, THIS FUNCTION IS ANALOGOUS TO iMesh_getNumOfType, > // TODO: WHICH TAKES THE ROOT SET OR ANY OTHER ENTITY SET. > // TODO: KDD ADDS: WE AGREED THAT ENTITY SETS COULD SPAN ACROSS PARTS AND > // TODO: PROCESSES. IF ENTITY SET HANDLES ARE, SAY, ADDRESSES, HOW DOES THE > // TODO: IMPLEMENTATION KNOW THAT ENTITY SET HANDLES ON DIFFERENT PROCESSES > // TODO: ACTUALLY ARE THE SAME ENTITY SET? 223a275,286 > // > // void prefix_getNumEntSetsPar(iMesh_Instance instance, > // const prefix_PartitionHandle partition_handle, > // const iBase_EntitySetHandle entity_set_handle, > // const int num_hops, int *num_sets, int *err); > // > // TODO: THIS FUNCTION WAS NOT ONE OF CARL'S SIXTEEN, BUT IT IS ANALOGOUS TO > // TODO: HIS FUNCTIONS. DO WE NEED IT? > // TODO: TIM SAYS "NO"; ENTITY SETS AREN'T IN PARTITIONS, SO THIS FUNCTION IS > // TODO: POORLY DEFINED. I AGREE, AS I COULDN'T RIGHT AN APPROPRIATE COMMENT > // TODO: DESCRIBING THE FUNCTION. SO I'LL COMMENT IT OUT FOR NOW (AND DELETE > // TODO: IT LATER IF THERE ARE NO OBJECTIONS). 225,247d287 < void prefix_getNumEntSetsPar(iMesh_Instance instance, < const prefix_PartitionHandle partition_handle, < const iBase_EntitySetHandle entity_set_handle, < const int num_hops, int *num_sets, int *err); < < // KDD: THIS FUNCTION WAS NOT ONE OF CARL'S SIXTEEN, BUT IT IS ANALOGOUS TO < // KDD: HIS FUNCTIONS. DO WE NEED IT? < < //////////////////////////////// < // Manage global IDs of entities that are partitioned. < // + set/retrieve global IDs; generate global IDs; < // set/retrieve global ID size; map between entities and global IDs; < // compare global IDs. Since there was little disagreement with < // Vitus'/Karen's document on global IDs, we will use it in the first < // draft with modifications to associate the "global" nature of the < // IDs with partitions; these changes address some of Tim's concerns. < // We will keep the helper functions defined, rather than require the < // application to manage them with special tags. < // KDD: The more I think about this, the more I think it should be a service, < // KDD: not part of the interface. Perhaps it should be part of the dynamic < // KDD: load balancing service, since we are the only ones who care to use it < // KDD: currently. < // KDD: Does anyone else agree? 266c306 < // from the partition, destroy the part, and set the part handle to NULL. --- > // from the partition, destroy the part, and invalidate the part handle. 275a316,318 > // Note that part handles are local as described above. > // TODO: SEE DISCUSSION OF PART IDS IN INITIAL COMMENTS. > // TODO: MAY NOT NEED THESE FUNCTIONS. 277,278c320 < void prefix_getPartIdsFromPartHandle(iMesh_Instance instance, < const prefix_PartitionHandle partition_handle, --- > void prefix_getPartIdFromPartHandle(iMesh_Instance instance, 284d325 < const prefix_PartitionHandle partition_handle, 292a334,336 > // TODO: SEE DISCUSSION OF PART IDS IN INITIAL COMMENTS. > // TODO: MAY NOT NEED THESE FUNCTIONS; MAY REPLACE THEM WITH TEST FOR > // TODO: LOCAL OR REMOTE PART HANDLE. 294c338 < void prefix_getPartHandlesFromPartId(iMesh_Instance instance, --- > void prefix_getPartHandleFromPartId(iMesh_Instance instance, 309a354,356 > // TODO: NEED NEW DEFINITION OF PART NEIGHBOR. > // TODO: ARE THESE FUNCTIONS REQUIRED TO BE LOCAL (THROUGH UPDATES FROM > // TODO: prefix_updatePartitionPar)? 361,362c408 < void prefix_getNumPartBdryEntities(iMesh_Instance instance, < /*in*/ const prefix_PartitionHandle partition_handle, --- > void prefix_getNumPartBdryEnts(iMesh_Instance instance, 374,375c420 < void prefix_getPartBdryEntities(iMesh_Instance instance, < /*in*/ const prefix_PartitionHandle partition_handle, --- > void prefix_getPartBdryEnts(iMesh_Instance instance, 387a433,434 > // Functionality for getNext, reset, and end is > // provided through the regular iMesh iterator functions. 390d436 < /*in*/ const prefix_PartitionHandle partition_handle, 398,401d443 < // KDD: Do we need getNextPartBdryEntIter, resetPartBdrEntIter, and < // KDD: endPartBdryEntIter? Or can the getNextEntIter, resetEntIter, and < // KDD: endEntIter be used with the iterator produced by initPartBdryEntIter? < 403d444 < /*in*/ const prefix_PartitionHandle partition_handle, 412,415d452 < // KDD: Do we need getNextPartBdryEntArrIter, resetPartBdrEntArrIter, and < // KDD: endPartBdryEntArrIter? Or can the getNextEntArrIter, resetEntArrIter, < // KDD: and endEntArrIter be used with the iterator produced by < // KDD: initPartBdryEntArrIter? 421,423c458,459 < // KDD: If parts don't need their partition handles, this operation can < // KDD: be accomplished by functions that add/remove entities to/from < // KDD: EntitySets. --- > // On-process add/remove can be accomplished by functions > // that add/remove entities to/from EntitySets. 424a461,462 > // TODO: ONKAR SAYS #define CAN BE PROBLEMATIC FOR FUNCTION NAMES. > // TODO: WE'LL WORK OUT THE RIGHT MECHANISM. 437,448c475,505 < // Note: Some set-up communication may be needed for the receive to < // determine what messages it is waiting for. KDD: Agreed! < // Note: Using a pair of calls allows at least some latency hiding. < < void prefix_sendEntArrToParts(iMesh_Instance instance, < /*in*/ const prefix_PartitionHandle partition_handle, < /*in*/ const prefix_PartHandle source_part_handle, < /*in*/ const iBase_EntitySetHandle *entity_set_handles, < /*in*/ const int entity_handles_size, < /*in*/ const int *target_part_ids, < /*in*/ int command_code, // e.g., MIGRATE,COPY < int *err); --- > // The implementation has everything it needs to determine sends and > // receives. If desired, it can send and post non-blocking receives. > // Upon return, the application can do other stuff for latency hiding. > > void prefix_sendEntArrToPartsPar(iMesh_Instance instance, > /*in*/ const prefix_PartitionHandle partition_handle, > /*in*/ const iBase_EntityHandle *entity_handles, > /*in*/ const int entity_handles_size, > /*in*/ const int *target_part_ids, > /*in*/ int command_code, // e.g., MIGRATE,COPY > /*in*/ int update_ghost, // e.g., YES,NO > /*in*/ int message_tag, > int *err); > > // The implementation can post blocking receives or wait for non- > // blocking receives previously posted. Targets are correct, because > // there may be multiple parts on a processor and the application does > // not need to know sources. The message_tag ties > // a send and receive pair together. > > void prefix_recvEntArrToPartsPar(iMesh_Instance instance, > /*in*/ const prefix_PartitionHandle partition_handle, > /*inout*/ iBase_EntityHandle **entity_handles, > /*inout*/ int *entity_handles_size, > /*out*/ int *entity_handles_allocated, > /*inout*/ int *target_part_ids, > /*out*/ int *target_part_ids_allocated, > /*inout*/ int command_code, // e.g., MIGRATE,COPY > /*in*/ int update_ghost, // e.g., YES,NO > /*in*/ int message_tag, > int *err); 450,459d506 < void prefix_receiveEntArrToParts(iMesh_Instance instance, < /*in*/ const prefix_PartitionHandle partition_handle, < /*in*/ const prefix_PartHandle source_part_handle, < /*inout*/ iBase_EntitySetHandle **entity_set_handles, < /*inout*/ int *entity_handles_size, < /*out*/ int *entity_handles_allocated, < /*inout*/ int *target_part_ids, < /*out*/ int *target_part_ids_allocated, < /*inout*/ int command_code, // e.g., MIGRATE,COPY < int *err); 462,464c509,512 < // Provide entity information about a part; e.g., given a partition handle and < // a part handle, return the number of entities in the part, lists of < // entities in the part, etc. --- > // Provide entity information about a part. > // Given an entity set handle > // and a part handle, return the number of entities of given type/topo > // that are in both the part and the entity set. 467d514 < const prefix_PartitionHandle partition_handle, 472d518 < const prefix_PartitionHandle partition_handle, 477,488c523,540 < void prefix_getEntSets(iMesh_Instance instance, < const prefix_PartitionHandle partition_handle, < const prefix_PartHandle part_handle, < const iBase_EntitySetHandle entity_set_handle, < const int num_hops, < iBase_EntitySetHandle** contained_set_handles, < int* contained_set_handles_allocated, < int* contained_set_handles_size, int *err); < < // KDD: THE ABOVE FUNCTION WAS NOT ONE OF CARL'S SIXTEEN, BUT IT IS ANALOGOUS < // KDD: TO HIS FUNCTIONS. DO WE NEED IT? < --- > // void prefix_getEntSets(iMesh_Instance instance, > // const prefix_PartHandle part_handle, > // const iBase_EntitySetHandle entity_set_handle, > // const int num_hops, > // iBase_EntitySetHandle** contained_set_handles, > // int* contained_set_handles_allocated, > // int* contained_set_handles_size, int *err); > // > // TODO: THE ABOVE FUNCTION WAS NOT ONE OF CARL'S SIXTEEN, BUT IT IS ANALOGOUS > // TODO: TO HIS FUNCTIONS. DO WE NEED IT? > // TODO: TIM SAYS "NO"; ENTITY SETS AREN'T IN PARTITIONS, SO THIS FUNCTION IS > // TODO: POORLY DEFINED. I AGREE, AS I COULDN'T RIGHT AN APPROPRIATE COMMENT > // TODO: DESCRIBING THE FUNCTION. SO I'LL COMMENT IT OUT FOR NOW (AND DELETE > // TODO: IT LATER IF THERE ARE NO OBJECTIONS). > > // Given an entity set handle > // and a part handle, return vertex information for vertices > // that are in both the part and the entity set. 490d541 < const prefix_PartitionHandle partition_handle, 502d552 < const prefix_PartitionHandle partition_handle, 518a569,571 > // Given an entity set handle > // and a part handle, return entity handles for entities > // that are in both the part and the entity set. 520d572 < const prefix_PartitionHandle partition_handle, 531d582 < const prefix_PartitionHandle partition_handle, 549c600,604 < // Provide entity and array iterators within a part. --- > // Provide entity and array iterators for entities within both a given part > // and a given entity set. > // Functionality for getNext, reset, and end is > // provided through the regular iMesh iterator functions. > 551d605 < const prefix_PartitionHandle partition_handle, 558,574d611 < void prefix_getNextEntIter(iMesh_Instance instance, < const prefix_PartitionHandle partition_handle, < prefix_PartHandle part_handle, < iMesh_EntityIterator entity_iterator, < iBase_EntityHandle* entity_handle, < int *has_data, < int *err); < void prefix_resetEntIter(iMesh_Instance instance, < const prefix_PartitionHandle partition_handle, < prefix_PartHandle part_handle, < iMesh_EntityIterator entity_iterator, < int *err); < void prefix_endEntIter(iMesh_Instance instance, < const prefix_PartitionHandle partition_handle, < prefix_PartHandle part_handle, < iMesh_EntityIterator entity_iterator, < int *err); 576d612 < const prefix_PartitionHandle partition_handle, 584,606d619 < void prefix_getNextEntArrIter(iMesh_Instance instance, < const prefix_PartitionHandle partition_handle, < prefix_PartHandle part_handle, < iMesh_EntityArrIterator entArr_iterator, < iBase_EntityHandle** entity_handles, < int* entity_handles_allocated, < int* entity_handles_size, < int *has_data, < int *err); < void prefix_resetEntArrIter(iMesh_Instance instance, < const prefix_PartitionHandle partition_handle, < prefix_PartHandle part_handle, < iMesh_EntityArrIterator entArr_iterator, < int *err); < void prefix_endEntArrIter(iMesh_Instance instance, < const prefix_PartitionHandle partition_handle, < prefix_PartHandle part_handle, < iMesh_EntityArrIterator entArr_iterator, < int *err); < < // KDD: Do we need prefix_getNext..., prefix_reset..., and < // KDD: prefix_end...? Or can the iMesh_getNext..., iMesh_reset..., and < // KDD: iMesh_end... be used with the iterator produced by prefix_init...? 617,619c630,634 < // Must return an error code if the entity is not in the < // partition (e.g., if the partition assigns surfaces to parts, it < // doesn't make sense to ask which part owns a given region). --- > // Return an error code if an entity is not in the partition. > // TODO: SHOULD MORE PRECISELY DEFINE WHEN ERROR CODE IS RETURNED. > // TODO: E.G., WHEN AN ENTITY IS NOT OWNED BY ANY PROCESSES IN THE > // TODO: PARTITIONS COMMUNICATOR; WHEN AN ENTITY IS NOT "CONNECTED" TO > // TODO: ANY ENTITIES USED TO GENERATE THE PARTITION. 621c636 < void prefix_getEntityOwner(iMesh_Instance instance, --- > void prefix_getEntOwnerPartId(iMesh_Instance instance, 627c642 < void prefix_getEntityOwnerArr(iMesh_Instance instance, --- > void prefix_getEntOwnerPartIdArr(iMesh_Instance instance, 636c651 < // Provide entity categorization within part (boundary, copy, owned, etc.): --- > // Provide entity categorization within part. 638c653 < // flag indicating whether the entity is owned by the part or is a copy. --- > // flag indicating whether the entity is owned by the part. 641d655 < /*in*/ const prefix_PartitionHandle partition_handle, 648d661 < /*in*/ const prefix_PartitionHandle partition_handle, 661d673 < /*in*/ const prefix_PartitionHandle partition_handle, 668d679 < /*in*/ const prefix_PartitionHandle partition_handle, 682a694,696 > > // TODO: ONKAR SAYS THESE FUNCTIONS DO NOT REQUIRE COMMUNICATION, BUT > // TODO: FOR MANY OF THEM, I DON'T UNDERSTAND HOW THEY DON'T. 686a701,705 > // TODO: LORI OBSERVES: I STRUGGLE WITH THE copyEntOnPart FUNCTIONS... I > // TODO: DON'T FULLY UNDERSTAND WHAT THIS ADDS TO THE INTERFACE AND i THINK IT > // TODO: COULD LEAD TO HEADACHES WHEN THINKING ABOUT CONSISTENCY OF > // TODO: INFORMATION ACROSS PROCESSORS. > 696c715 < // of copies of the entity on processes in the partition's communicator. --- > // of copies of the entity in the partition. 703a723,733 > // + Given a partition handle and an entity handle, return the part IDs > // of copies of the entity in the partition. (Requested by Onkar.) > > void prefix_getCopiesEntPartIDs(iMesh_Instance instance, > /*in*/ const prefix_PartitionHandle partition_handle, > /*in*/ const iBase_EntityHandle entity_handle, > /*inout*/ int** part_ids, > /*inout*/ int* part_ids_allocated, > /*out*/ int* part_ids_size, > int *err); > 731c761,774 < --- > // TODO: TIM ASKS WHETHER THESE FUNCTIONS COMMUNICATE. I HAD ASSUMED > // TODO: THEY DID, SINCE THEY TOOK PARTITION HANDLES AND TARGET PART IDS > // TODO: AS ARGUMENTS. BUT THEN THEY WOULD HAVE TO BE CALLED > // TODO: SYNCHRONOUSLY. HOW WOULD THAT WORK? AND HOW WOULD THEY DIFFER > // TODO: FROM prefix_sendEntArrToPartsPar/prefix_recvEntArrToPartsPar? > > // TODO: LORI OBSERVES: SEEMS AS THOUGH addCopyEnt/rmvCopyEnt COULD BE > // TODO: COMBINED WITH THE OTHER ADD FUNCTIONS (THAT ARE LIKE ENTITYSET > // TODO: FUNCTIONS) WITH AN APPROPRIATE ENUMERATOR (e.g. OWNED, COPY). > // TODO: I THINK THAT ASSUMES THE FUNCTIONS WORK LOCALLY. > > // TODO: THERE IS TOO MUCH CONFUSION ON THESE FUNCTIONS > // TODO: FOR ME TO MAKE CHANGES. WE'LL DISCUSS THEM IN A PHONE CONF. > // TODO: WE NEED TO DETERMINE WHAT CAPABILITY WE NEED. 738c781 < void prefix_removeCopyEnt(iMesh_Instance instance, --- > void prefix_rmvCopyEnt(iMesh_Instance instance, 864a908,910 > Ghosts and copies: > - From Tim: Need functionality to exchange tag data for entities on > interfaces and ghost entities. 870,871c916,917 < $Date: 2008/01/22 18:29:30 $ < $Revision: 1.2 $ --- > $Date: 2008/02/11 21:19:16 $ > $Revision: 1.7 $