[mpich-discuss] ROMIO: view and type_indexed with holes at the end

[Pascal Deveze]

Hi Rob,

You have right, it is a misunderstanding, the problem is solved. Thanks 
for your quick help.

Pascal

Rob Ross a écrit :
> Hi Pascal,
>
> I believe that the issue is simply one of a misunderstanding of the 
> MPI datatype system.
>
> Zero length elements of an indexed type do not contribute to the 
> typemap, so they can be ignored. You can add as many zero-length 
> elements as you liked, at any position you wanted, and they will not 
> change the effective type. If you want to introduce holes as you say, 
> you should use MPI_Type_create_resized() instead.
>
> This mainly boils down to getting the extent of your type correct. You 
> are trying to get the extent of your type to be equal to disp[2] * 
> sizeof(integer) in your code, but my expectation is that if you used 
> MPI_Type_get_extent() on the type that you have created, you would see 
> sizeof(integer) instead -- there's only one integer of data. The 
> reason that you want the extent to be bigger is that when ROMIO tiles 
> the type, the next type is positioned at the end of the extent of the 
> previous one (more or less); that's what creates the hole at the end 
> of the type, not a zero-length element.
>
> Likewise the first zero-length element in your type doesn't really do 
> anything. Instead you want the LB of your type to be zero. This is 
> also handled with MPI_Type_create_resized().
>
> So try this instead.
>
> lng[0] = 1;
> dsp[0] = 1;
> MPI_Type_create_indexed(1, lng, dsp, MPI_INTEGER, &offtype);
> MPI_Type_create_resized(offtype, 0, hole_position * sizeof(integer), 
> &filetype);
> MPI_Type_commit(&filetype);
>
> ...
>
> Rob
>
>
>
> On Mar 8, 2010, at 7:23 AM, Pascal Deveze wrote:
>
>> Sorry, I forget the programm file
>> Here it is.
>>
>> Pascal
>>
>> Pascal Deveze a écrit :
>>> Hi all,
>>>
>>> I found a strange behaviour of  ROMIO with a type indexed datatype 
>>> that is contains holes.
>>> My definition:
>>>      lng[0]= 0;
>>>      dsp[0]= 0; ==> hole at first element
>>>      lng[1]= 1;
>>>      dsp[1]= 1; ===> one element
>>>      lng[2]= 0;
>>>      dsp[2]= 3; ====> hole at the end
>>>
>>>      MPI_Type_indexed(3, lng, dsp, MPI_INTEGER, &filetype);
>>>      MPI_Type_commit(&filetype);
>>>      MPI_File_open(MPI_COMM_SELF, filename, MPI_MODE_RDONLY , 
>>> MPI_INFO_NULL, &fh);
>>>      MPI_File_set_view(fh, 0, MPI_INTEGER, filetype,"native", 
>>> MPI_INFO_NULL);
>>>
>>> This definition works fine: One element with one hole at the 
>>> beginning and 2 holes at the end.
>>> It works also fine when dsp[2] > 3.
>>>
>>> But it does not work with dsp[2]=2. In that case, there is no hole 
>>> at the end.
>>>
>>> Attached is a small program to reproduce the error.
>>>
>>> I do not find if the MPI standard allows to introduce "holes" in the 
>>> indexed datatype (specifiing lng[i]=0) or does'nt.
>>> In any case, it seems to work in all cases excepted if only one hole 
>>> is specified at the end (dsp[2] = 2).
>>>
>>> Is this a bug in ROMIO or a limit of the MPI standard ?
>>>
>>> Pascal
>>>
>>>
>>>
>>> _______________________________________________
>>> mpich-discuss mailing list
>>> mpich-discuss at mcs.anl.gov
>>> https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss
>>>
>>>
>>
>> #include <stdio.h>
>> #include "mpi.h"
>>
>> #define SIZE 1000
>> char filename[256]="/mnt/fs3/devezep/VIEW_TEST";
>> int i, j, myid, dsp[3], lng[3], buffer[SIZE];
>> MPI_Status status;
>> MPI_File fh;
>> MPI_Datatype filetype;
>>
>> int main(int argc, char **argv) {
>>
>> MPI_Init(&argc, &argv);
>> MPI_Errhandler_set(MPI_COMM_WORLD, MPI_ERRORS_ARE_FATAL);
>> MPI_Comm_rank(MPI_COMM_WORLD, &myid);
>>
>> if (!myid) {
>>    MPI_File_open(MPI_COMM_SELF, filename, MPI_MODE_CREATE | 
>> MPI_MODE_RDWR , MPI_INFO_NULL, &fh);
>>    MPI_File_set_errhandler(fh, MPI_ERRORS_ARE_FATAL);
>>
>>    for (i=0; i<SIZE; i++) buffer[i] = i;
>>    MPI_File_write(fh, buffer, SIZE, MPI_INTEGER, &status);
>>    MPI_File_close(&fh);
>>
>> // loop for test :
>>    for (i=2 ; i<4 ; i++) {
>>       lng[0]= 0;
>>       dsp[0]= 0;
>>       lng[1]= 1;
>>       dsp[1]= 1;
>>       lng[2]= 0;
>>       dsp[2]= i;
>>
>>       MPI_Type_indexed(3, lng, dsp, MPI_INTEGER, &filetype);
>>       MPI_Type_commit(&filetype);
>>       MPI_File_open(MPI_COMM_SELF, filename, MPI_MODE_RDONLY , 
>> MPI_INFO_NULL, &fh);
>>       MPI_File_set_view(fh, 0, MPI_INTEGER, filetype,"native", 
>> MPI_INFO_NULL);
>>       MPI_File_read(fh, buffer, 5, MPI_INTEGER, &status);
>>
>>       printf("data read with view for i=%d => lng[0]=%d dsp[0]=%d 
>> lng[1]=%d dsp[1]=%d lng[2]=%d dsp[2]=%d :",
>>             i, lng[0], dsp[0], lng[1], dsp[1], lng[2], dsp[2]);
>>       for (j=0 ; j<5 ; j++) printf("%x ", buffer[j]);
>>       if (buffer[1] != (i+2)) printf("\n =======>  test KO for i=%d : 
>> buffer[1]=%d instead of %d \n", i, buffer[1], i+2);
>>       else printf("\n =======> test OK for i=%d\n", i);
>>       MPI_Type_free(&filetype);
>>       MPI_File_close(&fh);
>>    }
>> }
>> MPI_Barrier(MPI_COMM_WORLD);
>> MPI_Finalize();
>> }
>> _______________________________________________
>> mpich-discuss mailing list
>> mpich-discuss at mcs.anl.gov
>> https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss
>
> _______________________________________________
> mpich-discuss mailing list
> mpich-discuss at mcs.anl.gov
> https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss
>
>