[mpich-discuss] filetype_is_contig in ad_write_coll.c

[Wei-keng Liao]

In file mpich2-1.2.1/src/mpi/romio/adio/common/ad_write_coll.c,
function ADIOI_GEN_WriteStridedColl(), line 145, the call to
ADIOI_Datatype_iscontig() may not be necessary if cb_write is
not disabled, i.e. fd->hints->cb_write != ADIOI_HINT_DISABLE

Whether filetype is contiguous is actually already calculated when
calling ADIOI_Calc_my_off_len() at line 160 above, which returns
contig_access_count and if it is equal to 1, then filetype_is_contig
should be 1.

However, I found that in some cases, the function  
ADIOI_Datatype_iscontig()
does not report correctly. I tried a case that uses
MPI_Type_create_subarray() to create a contiguous filetype, but
ADIOI_Datatype_iscontig() returns a false. After checking the flatten  
type,
I found that the flatten type contains 2 or 3 non-contiguous segments,  
as
    flat_file->count == 2 or 3

In case of flat_file->count == 2, either flat_file->blocklens[0] or
flat_file->blocklens[1] is 0.

In case of flat_file->count == 3, both flat_file->blocklens[0] and
flat_file->blocklens[2] are 0s.

In both cases, there is only one element in flat_file->blocklens[]
which is not 0.

Attached is an example C program and a patch to ad_write_coll.c.
Running both can show the disagreement in filetype contiguity.
The patch also fix this problem.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: application/octet-stream
Size: 1542 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/mpich-discuss/attachments/20091221/3ec029b4/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: contig_subarray.c
Type: application/octet-stream
Size: 1655 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/mpich-discuss/attachments/20091221/3ec029b4/attachment-0001.obj>
-------------- next part --------------


Wei-keng