[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