StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
6012841
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2011-05-16T03:09:04.443
FavoriteCount
0
LastActivityDate
2011-05-16T14:12:52.603
LastEditDate
2011-05-16T14:12:52.603
LastEditorUserId
463827
OwnerUserId
463827
ParentId
6009081
PostTypeId
2
Score
3
ViewCount
0
LastEditorDisplayName
text
Body
So I'm a big fan of using <a href="http://www.mcs.anl.gov/research/projects/mpi/www/www3/MPI_Type_create_subarray.html" rel="nofollow">MPI_Type_create_subarray</a> for pulling out slices of arrays; it's easier to keep straight than vector types. In general, you can't use a single vector type to describe multi-d guardcells (because there are multiple strides, you need to create vectors of vectors), but I think because you're only using 1 guardcell in each direction here that you're ok. So let's consider the x-face GC; here you're sending an entire y-z plane to your x-neighbour. In memory, this looks like this given your array layout: <pre><code> +---------+ | @| | @| | @| | @| z=2 | @| +---------+ | @| | @| | @| z=1 | @| | @| +---------+ | @| ^| @| || @| z=0 y| @| | @| +---------+ x-> </code></pre> so you're looking to send count=(ny*nz) blocks of 1 value, each strided by nx. I'm assuming here nx, ny, and nz include guardcells, and that you're sending the corner values. If you're not sending corner values, subarray is the way to go. I'm also assuming, crucially, that g->data is a contiguous block of nx*ny*nz*2 (or 2 contiguous blocks of nx*ny*nz) doubles, otherwise all is lost. So your type create should look like <pre><code>MPI_Type_vector((g->ny*g->nz), 1, g->nx, MPI_DOUBLE, &face1); MPI_Type_commit(&face1); </code></pre> Note that we are sending a total of count*blocksize = ny*nz values, which is right, and we are striding over count*stride = nx*ny*nz memory in the process, which is also right. Ok, so the y face looks like this: <pre><code> +---------+ |@@@@@@@@@| | | | | | | z=2 | | +---------+ |@@@@@@@@@| | | | | z=1 | | | | +---------+ |@@@@@@@@@| ^| | || | z=0 y| | | | +---------+ x-> </code></pre> So you have nz blocks of nx values, each separated by stride nx*ny. So your type create should look like <pre><code>MPI_Type_vector(g->nz, g->nx, (g->nx)*(g->ny), MPI_DOUBLE, &face2); MPI_Type_commit(&face2); </code></pre> And again double-checking, you're sending count*blocksize = nz*nx values, striding count*stride = nx*ny*nz memory. Check. Finally, sending z-face data involves sending an entire x-y plane: <pre><code> +---------+ |@@@@@@@@@| |@@@@@@@@@| |@@@@@@@@@| z=2 |@@@@@@@@@| |@@@@@@@@@| +---------+ | | | | | | z=1 | | | | +---------+ | | ^| | || | z=0 y| | | | +---------+ x-> MPI_Type_vector(1, (g->nx)*(g->ny), 1, MPI_DOUBLE, &face3); MPI_Type_commit(&face3); </code></pre> And again double-checking, you're sending count*blocksize = nx*ny values, striding count*stride = nx*ny memory. Check. Update: I didn't take a look at your Sendrecvs, but there might be something there, too. Notice that you have to use a pointer to the first piece of data you're sending with an vector data type. First off, if you have array size nx in the x direction, and you have two guardcells (one on either side), your left guardcell is 0, right is nx-1, and your 'real' data extends from 1..nx-2. So to send your westmost data to your west neighbour, and to receive into your eastmost guardcell from your east neighbour, you would want <pre><code> /* Send to WEST receive from EAST */ MPI_Sendrecv(&(g->data)[current][0][0][g->nx-2], 1, face1, g->west, westtag, &(g->data)[current][0][0][0], 1, face1, g->east, westtag, MPI_COMM_WORLD, MPI_STATUS_IGNORE); /* Send to EAST receive from WEST */ MPI_Sendrecv(&(g->data)[current][0][0][1], 1, face1, g->east, easttag, &(g->data)[current][0][0][g->nx-1], 1, face1, g->west, easttag, MPI_COMM_WORLD, MPI_STATUS_IGNORE); </code></pre> (I like to use different tags for each stage of communication, helps keep things sorted.) Likewise for the other directions.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POHalo exchange not working properly in MPI
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USJonathan Dursi
UserOwnerUserId
1. USJonathan Dursi
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POHalo exchange not working properly in MPI
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.