Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI users] Type struct question
From: George Bosilca (bosilca_at_[hidden])
Date: 2011-11-11 10:55:21

On Nov 11, 2011, at 06:20 , Thomas Anderson wrote:

> I read doc explaining struct at
> I haven't used mpi so I have a newbie question.
> In the example function MPI_Type_struct(3, {2, 1, 3}, {0, 16, 26},
> {MPI_FLOAT, type1, MPI_CHAR} ) is executed where type1 is consisted of
> {(double,0)(char,8)}. The user defined datatype has extent 16 with
> displacement at 16. However, the third block starts from displacement
> 26. This seems to me the end of type1 (at 32) would overlap the
> displacement of MPI_CHAR (at 26). How does MPI solve this issue? Do
> they simply ignore the rest space because it is only char type in
> type1? Or if the type1 is defined by {(double, 0) (double, 8)}, won't
> the data in the second block be truncated?

If the overlap is on the gaps around the datatype, it is not that a big deal. I do not know how the other MPI libraries deal with this situation, but in Open MPI as long as there is no real overlap (in terms of real data) there will be no complaints from the library.

Your type1 contains the char at displacement 8. As, in the upper datatype, you start the type1 at position 16, the last real data will be the char at displacement 24, which is earlier than the double at displacement 26. So there is no overlap in this datatype.

If I dump with Open MPI this datatype, I get the following description:

Datatype 0x867270 id 69 size 20 align 8 opal_id 0 length 9 used 4
true_lb 0 true_ub 29 (true_extent 29) lb 0 ub 32 (extent 32)
nbElems 7 loops 0 flags 100 ()-------GD--[---][---]
--C---P-D--[---][---] OPAL_FLOAT4 count 2 disp 0x0 (0) extent 4 (size 8)
--C---P-D--[---][---] OPAL_FLOAT8 count 1 disp 0x10 (16) extent 8 (size 8)
--C---P-D--[---][---] OPAL_INT1 count 1 disp 0x18 (24) extent 1 (size 1)
--C---P-D--[---][---] OPAL_INT1 count 3 disp 0x1a (26) extent 1 (size 3)

which corroborate what I describe above.


> Thanks.
> _______________________________________________
> users mailing list
> users_at_[hidden]