[petsc-users] A problem with MPI Derived Data Type and 'calloc'
Zhenglun (Alan) Wei
zhenglun.wei at gmail.com
Thu Apr 19 09:52:04 CDT 2012
Thank you so much, Dr. Knepley.
Alan
On 4/19/2012 9:51 AM, Matthew Knepley wrote:
> On Thu, Apr 19, 2012 at 10:49 AM, Zhenglun (Alan) Wei
> <zhenglun.wei at gmail.com <mailto:zhenglun.wei at gmail.com>> wrote:
>
> Dear Dr. Knepley,
> It is very nice to hear that. I will read the manual. Do we
> have any examples showing its functions?
>
>
> Lots of examples. Start with SNES ex5 and ex19.
>
> Matt
>
> thank you so much,
> Alan
> On 4/19/2012 9:35 AM, Matthew Knepley wrote:
>> On Thu, Apr 19, 2012 at 10:18 AM, Zhenglun (Alan) Wei
>> <zhenglun.wei at gmail.com <mailto:zhenglun.wei at gmail.com>> wrote:
>>
>> "
>> 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.
>>
>> *_What is the reason for not using DMDA?_
>> *In 2D, I established a 2D array for data communication
>> between nodes by using MPI derived data type. It allows me to
>> easily communicate both contiguous (i.e. MPI_TYPE_CONTIGUOUS)
>> and non-contiguous (i.e. MPI_TYPE_VECTOR) data. That is why I
>> use this similar approach in 3D, though an additional data
>> type, i.e. MPI_TYPE_INDEXED, need to be used. Does DMDA have
>> those type of function or derived data type?
>>
>>
>> It definitely does communication between the local pieces. Do you
>> want something else?
>>
>> "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?"
>>
>>
>> _*What do you mean by neighboring? If it is jsut stencil
>> neighbors, then use a local vector.*_
>> When I send and receive data with MPI_Send and MPI_RECV, I
>> need provide the 'destination' (in MPI_Send refer
>> to'http://www.mcs.anl.gov/research/projects/mpi/www/www3/MPI_Send.html')
>> and 'source' (in MPI_RECV refer
>> to'http://www.mcs.anl.gov/research/projects/mpi/www/www3/MPI_Recv.html').
>> In a 2D problem with Cartesian grid, 4 processes divide the
>> whole domain to 4 sub-domain.
>> ----------------------------
>> 2 | 3 |
>> ----------------------------
>> 0 | 1 |
>> ---------------------------
>> Then, for node 1, the neighboring nodes are '0' and '3',
>> which '0' is the left node and '3' is the top node. I wonder
>> if PETSc has any function that I can call to obtain those
>> neighboring nodes so that I do not need to construct my
>> function.
>>
>>
>> Yes, it looks like you should just use a DMDA. See the manual
>> section.
>>
>> Matt
>>
>> I'm sorry for confusing you.
>>
>> thanks in advance,
>> Alan
>>
>> On 4/19/2012 4:52 AM, Matthew Knepley wrote:
>>> On Wed, Apr 18, 2012 at 3:52 PM, Alan Wei
>>> <zhenglun.wei at gmail.com <mailto: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.
>>>
>>>
>>> What is the reason for not using DMDA?
>>>
>>> 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?
>>>
>>>
>>> What do you mean by neighboring? If it is jsut stencil
>>> neighbors, then use a local vector.
>>>
>>> Matt
>>>
>>> thanks,
>>> Alan
>>>
>>> On Fri, Apr 13, 2012 at 5:41 PM, Jed Brown
>>> <jedbrown at mcs.anl.gov <mailto:jedbrown at mcs.anl.gov>> wrote:
>>>
>>> On Fri, Apr 13, 2012 at 17:38, Zhenglun (Alan) Wei
>>> <zhenglun.wei at gmail.com
>>> <mailto: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.
>>>
>>>
>>>
>>>
>>>
>>> --
>>> What most experimenters take for granted before they begin
>>> their experiments is infinitely more interesting than any
>>> results to which their experiments lead.
>>> -- Norbert Wiener
>>
>>
>>
>>
>> --
>> What most experimenters take for granted before they begin their
>> experiments is infinitely more interesting than any results to
>> which their experiments lead.
>> -- Norbert Wiener
>
>
>
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which
> their experiments lead.
> -- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120419/66877bae/attachment.htm>
More information about the petsc-users
mailing list