itaps-parallel Estimated implementation levels on ITAPS parallel interface routines

[Devine, Karen D]

Ting and Tim:  Thanks for your review. Please see my comments below. --Karen

On 6/10/08 10:24 AM, "Tim Tautges" <tautges at mcs.anl.gov> wrote:
>
> txie at scorec.rpi.edu wrote:
>> In the review, we also found two possible problems as follows:
>>
>> 1. Type definitions are needed for iMeshP_PartitionHandle,
>> iMeshP_PartHandle, iMeshP_RequestHandle, iMeshP_Status and etc, just as
>> what we defined in iBase.h before.
>>
>
> - IMO, the part/partition handle types should be identical to
> entitysethandle types (not typedef'd to the iMesh types, but whatever
> those are typedef'd to, probably void*?
>
> - RequestHandle, StatusHandle should be typedef'd to the equivalent MPI
> entities, IMO.

No, I think our RequestHandle is an implementation-dependent handle
including more than an MPI request.  An iMeshP request is a request for a
mesh operation, not a single communication.  For example,
iMeshP_exchEntArrToPartsAll likely issues multiple MPI_Sends and MPI_Irecvs,
but it returns only one iMeshP request handle, not one for each MPI_Irecv.
Then, iMeshP_WaitAll waits until the iMeshP request is done; in the example,
iMeshP_WaitAll on a single iMeshP request would wait until all the issued
MPI_Irecvs were satisfied.  Typedef'ing the iMeshP request to MPI Request
would not work in this example.

Ting is correct that we don't have these handles defined.  I assumed they
would be cast-able to void*, just as all our handles are.

>
>> 2. To support the parallel mesh adaptivity, maybe the Parallel File I/O
>> routines are missing to load/write-out partitioned mesh.
>>
>
> I thought we were going to handle that through the options to iMesh_load
> (that's the way I've been doing it in MOAB, anyway).

We have not discussed I/O yet; it will be a hot topic coming up this fall.
It will be good to have some examples to work from.  Tim, will your reader
support initial partitioning of Exodus files and/or reading Nemesis?