We have the following further questions about iMeshP. 1. iMeshP_destroyPartitionAll states that the partition is not invalidated upon return. If this means that the partition is not freed, when and how will it be freed? If not, what does the statement mean? 2. Several migration functions take in the destination part ids of entities as they should. However, there is no function to get remote part ids from a partition. How is the user supposed to know which part id to migrate to, or are we missing something? 3. iMeshP_exchEntArrToPartsAll has a command_code input defined as "Flag indicating whether to migrate the entities or only make copies". It is unclear which option is 1 and which option is 0. 4. This is nitpicking, but iMeshP_getPartHandlesFromPartsIdsArr is misnamed. It should be ...PartIds... not ...PartsIds... Thanks, saurabh
Saurabh Tendulkar wrote:
We have the following further questions about iMeshP.
1. iMeshP_destroyPartitionAll states that the partition is not invalidated upon return. If this means that the partition is not freed, when and how will it be freed? If not, what does the statement mean?
There was some debate at one time as to whether or not this type of function should be passed a partition handle by copy (as it is now) or instead be passed a reference to a partition handle so that the implementation can nullify the variable storing the handle. I assume that this comment refers to the passed variable containing the handle value, rather than the partition itself.
2. Several migration functions take in the destination part ids of entities as they should. However, there is no function to get remote part ids from a partition. How is the user supposed to know which part id to migrate to, or are we missing something?
iMeshP_getPartNBors(Arr) iMeshP_getEntOwnerPart(Arr) iMeshP_getCopyParts - jason
Jason Kraftcheck wrote:
Saurabh Tendulkar wrote:
We have the following further questions about iMeshP.
1. iMeshP_destroyPartitionAll states that the partition is not invalidated upon return. If this means that the partition is not freed, when and how will it be freed? If not, what does the statement mean?
There was some debate at one time as to whether or not this type of function should be passed a partition handle by copy (as it is now) or instead be passed a reference to a partition handle so that the implementation can nullify the variable storing the handle. I assume that this comment refers to the passed variable containing the handle value, rather than the partition itself.
If I understand this correctly then, the statement should be disregarded because it doesn't make sense in the context of the handle being passed by value?
2. Several migration functions take in the destination part ids of entities as they should. However, there is no function to get remote part ids from a partition. How is the user supposed to know which part id to migrate to, or are we missing something?
iMeshP_getPartNBors(Arr) iMeshP_getEntOwnerPart(Arr) iMeshP_getCopyParts
These are just returning the part wrt an entity (ownership/copy) or neighboring a part. Isn't there anything that returns them in a global sense (eg. return all part ids on process with given rank)? Thanks, saurabh
Saurabh Tendulkar wrote:
Jason Kraftcheck wrote:
Saurabh Tendulkar wrote:
We have the following further questions about iMeshP.
1. iMeshP_destroyPartitionAll states that the partition is not invalidated upon return. If this means that the partition is not freed, when and how will it be freed? If not, what does the statement mean?
There was some debate at one time as to whether or not this type of function should be passed a partition handle by copy (as it is now) or instead be passed a reference to a partition handle so that the implementation can nullify the variable storing the handle. I assume that this comment refers to the passed variable containing the handle value, rather than the partition itself.
If I understand this correctly then, the statement should be disregarded because it doesn't make sense in the context of the handle being passed by value?
That is my interpretation.
2. Several migration functions take in the destination part ids of entities as they should. However, there is no function to get remote part ids from a partition. How is the user supposed to know which part id to migrate to, or are we missing something?
iMeshP_getPartNBors(Arr) iMeshP_getEntOwnerPart(Arr) iMeshP_getCopyParts
These are just returning the part wrt an entity (ownership/copy) or neighboring a part. Isn't there anything that returns them in a global sense (eg. return all part ids on process with given rank)?
There doesn't appear to be. It seems that there should be a iMeshP_getGlobalParts, as we have: iMeshP_getNumGlobalParts, iMeshP_getNumLocalParts, and iMeshP_getLocalParts. On the other hand, that's typically all-to-all communication and perhaps the intent was to discourage it. It also may not scale well to very large machines for other reasons (big array to hold all part ids.) Perhaps you could just assume that parts have consecutive IDs (which I think is the case for all implementations), and therefore assume that the global part list is 1 to n, where n is the result of iMeshP_getNumGlobalParts. - jason
As Jason mentioned, due to all-to-all communication and size of array it was decided to not have process-to-parts mapping, especially in cases where one can have non-uniform number of parts across processes (I think this possibility is allowed)? As per last discussions, Part IDs will be globally unique but not necessarily consecutive (see iMeshP.h) - Onkar
These are just returning the part wrt an entity (ownership/copy) or neighboring a part. Isn't there anything that returns them in a global sense (eg. return all part ids on process with given rank)?
There doesn't appear to be. It seems that there should be a iMeshP_getGlobalParts, as we have: iMeshP_getNumGlobalParts, iMeshP_getNumLocalParts, and iMeshP_getLocalParts. On the other hand, that's typically all-to-all communication and perhaps the intent was to discourage it. It also may not scale well to very large machines for other reasons (big array to hold all part ids.) Perhaps you could just assume that parts have consecutive IDs (which I think is the case for all implementations), and therefore assume that the global part list is 1 to n, where n is the result of iMeshP_getNumGlobalParts.
- jason
participants (3)
-
Jason Kraftcheck -
Onkar Sahni -
Saurabh Tendulkar