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

[Rob Ross]

Glad that worked. -- Rob

On Mar 9, 2010, at 3:09 AM, Pascal Deveze wrote:

> 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
>>
>>
>
> _______________________________________________
> mpich-discuss mailing list
> mpich-discuss at mcs.anl.gov
> https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss