[petsc-users] A problem with MPI Derived Data Type and 'calloc'

Kevin Green kevin.richard.green at gmail.com
Wed Apr 18 16:26:32 CDT 2012


If I could just wedge myself in here for a second... I recall fiddling with
a 3d contiguous allocation problem a while back.  My solution is
essentially the same, but the pointers to pointers are allocated in the
space before the array data... Nice thing is, you only need  double ***M
(or whatever type you want, I think I even have a templated version sitting
around somewhere...) outside of the function.

double*** contiguous3(int icount,
              int jcount,
              int kcount)
// Generates a contiguously allocated (row major) array for 3 dimensions.
// Array can be accessed as M[i][j][k], and also taking
// m = &M[0][0][0] (for pointer m) allows m[i]
// Allocated memory can be freed with a single call to free(M)
{
  int ii, jj;
  int typeSize = sizeof(double);
  void*** iret = (void***)malloc(icount*sizeof(void***) +
                 icount*jcount*sizeof(void**) +
                 icount*jcount*kcount*typeSize);
  void** jret = (void**)(iret + icount);
  char* kret = (char*)(jret + icount*jcount);
  for(ii=0;ii<icount;++ii){
    iret[ii] = &jret[ii*jcount];
  }
  for(ii=0;ii<icount;++ii){
    for(jj=0;jj<jcount;++jj){
      jret[ii*jcount+jj] = &kret[ii*jcount*kcount*typeSize +
                 jj*kcount*typeSize];
    }
  }
  return (double***)iret;
}

Cheers,
Kevin



On Wed, Apr 18, 2012 at 3:52 PM, Alan Wei <zhenglun.wei at gmail.com> wrote:

> Dear all,
>     I hope you're having a nice day. I have a further question on this
> issue in 3D.
> 1, Following the idea of Dr. Brown and Dr. Knepley, I finished a 2D test,
> which works very fine. Here, I did it in 3D by
> "
>     TESTVAR ***a, ***b, ***c;
>     TESTVAR **aa, **bb, **cc;
>     TESTVAR *arraya, *arrayb, *arrayc;
>
>     arraya = (TESTVAR*) calloc(SIZE*SIZE*SIZE, sizeof(TESTVAR));
>     arrayb = (TESTVAR*) calloc(SIZE*SIZE*SIZE, sizeof(TESTVAR));
>     arrayc = (TESTVAR*) calloc(SIZE*SIZE*SIZE, sizeof(TESTVAR));
>
>     aa =(TESTVAR**) calloc(SIZE*SIZE, sizeof(TESTVAR*));
>     bb =(TESTVAR**) calloc(SIZE*SIZE, sizeof(TESTVAR*));
>     cc =(TESTVAR**) calloc(SIZE*SIZE, sizeof(TESTVAR*));
>
>     for(i = 0; i < SIZE*SIZE; i++) {
>       aa[i] = &arraya[i*SIZE];
>       bb[i] = &arrayb[i*SIZE];
>       cc[i] = &arrayc[i*SIZE];
>     }
>
>     a =(TESTVAR***) calloc(SIZE*SIZE, sizeof(TESTVAR**));
>     b =(TESTVAR***) calloc(SIZE*SIZE, sizeof(TESTVAR**));
>     c =(TESTVAR***) calloc(SIZE*SIZE, sizeof(TESTVAR**));
>
>     for(i = 0; i < SIZE; i++) {
>       a[i] = &aa[i*SIZE];
>       b[i] = &bb[i*SIZE];
>       c[i] = &cc[i*SIZE];
>     }
> "
>   It works. However, I wonder if there is any other good ideas for 3D
> problem other than this kinda of 'two-layer' approach.
>
> 2, I have a little question on PETSc about 3D processor ordering. Does
> PETSc have any function giving me the nodes/rank number of neighboring
> nodes/ranks? Are those 'Application Ordering' functions applicable for my
> case?
>
> thanks,
> Alan
>
> On Fri, Apr 13, 2012 at 5:41 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
>> On Fri, Apr 13, 2012 at 17:38, Zhenglun (Alan) Wei <
>> zhenglun.wei at gmail.com> wrote:
>>
>>>     I have a final question on it. Is it taken a lot of memory for doing
>>> this? As I understand, pointers won't occupy many memories and it works
>>> like an alias. It will not, to my limit knowledge, take much extra memory
>>> by doing this.
>>
>>
>> A pointer takes about as much space as a floating point value, so that
>> array of pointers costs about 1*N compared to the N*N matrix.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120418/8c2aee5f/attachment.htm>


More information about the petsc-users mailing list