Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] MPI-Send for entire entire matrix when allocating memory dynamically
From: Justin Luitjens (luitjens_at_[hidden])
Date: 2009-10-29 15:31:34

Why not do something like this:

double **A=new double*[N];
double *A_data new double [N*N];

for(int i=0;i<N;i++)

This way you have contiguous data (in A_data) but can access it as a 2D
array using A[i][j].

(I haven't compiled this but I know we represent our matrices this way).

On Thu, Oct 29, 2009 at 12:30 PM, Natarajan CS <csnataraj_at_[hidden]> wrote:

> Hi
> thanks for the quick response. Yes, that is what I meant. I thought
> there was no other way around what I am doing but It is always good to ask a
> expert rather than assume!
> Cheers,
> C.S.N
> On Thu, Oct 29, 2009 at 11:25 AM, Eugene Loh <Eugene.Loh_at_[hidden]> wrote:
>> Natarajan CS wrote:
>> Hello all,
>>> Firstly, My apologies for a duplicate post in LAM/MPI list I have
>>> the following simple MPI code. I was wondering if there was a workaround for
>>> sending a dynamically allocated 2-D matrix? Currently I can send the matrix
>>> row-by-row, however, since rows are not contiguous I cannot send the entire
>>> matrix at once. I realize one option is to change the malloc to act as one
>>> contiguous block but can I keep the matrix definition as below and still
>>> send the entire matrix in one go?
>> You mean with one standard MPI call? I don't think so.
>> In MPI, there is a notion of derived datatypes, but I'm not convinced this
>> is what you want. A derived datatype is basically a static template of data
>> and holes in memory. E.g., 3 bytes, then skip 7 bytes, then another 2
>> bytes, then skip 500 bytes, then 1 last byte. Something like that. Your 2d
>> matrices differ in two respects. One is that the pattern in memory is
>> different for each matrix you allocate. The other is that your matrix
>> definition includes pointer information that won't be the same in every
>> process's address space. I guess you could overcome the first problem by
>> changing alloc_matrix() to some fixed pattern in memory for some r and c,
>> but you'd still have pointer information in there that you couldn't blindly
>> copy from one process address space to another.
>> _______________________________________________
>> users mailing list
>> users_at_[hidden]
> _______________________________________________
> users mailing list
> users_at_[hidden]