Barry,
Thanks! I have another question. The user manual says:
PETSc currently provides no container for multiple arrays
sharing the same distributed array communication; note, however, that the dof
parameter handles many cases of interest.
In my application, each space location will have on the order of hundreds of
values associated with it (which I believe translates to dof=O(100) - I don't
see the "degrees of freedom" explicitly defined anywhere). However, when
communicating ghost values, not all of those degrees of freedom should be
exchanged at once. I need to be able to exchange one at a time.
It sounds like what I may want to do is use VecCreateGhost(), which would allow
me to define exactly where the ghost points are, and then duplicate that vector
using VecDuplicateVecs() for each DOF. I can then scatter the vectors
individually as the need arises. Does that sound reasonable?
Greg
>-----Original Message-----
>From: Barry Smith [mailto:[email protected]]
>Sent: Friday, February 21, 2014 12:21 PM
>To: Fischer, Greg A.
>Cc: [email protected]
>Subject: Re: [petsc-users] partial stencil in DMDA?
>
>
>On Feb 21, 2014, at 11:02 AM, Fischer, Greg A.
><[email protected]<mailto:[email protected]>>
>wrote:
>
>> Hello,
>>
>> I'm interested in using PETSc to manage distributed arrays. Based on my
>reading about the DMDA objects, I see that ghost points can be
>communicated in box-type stencils or star-type stencils.
>>
>> For my application, assume that I have a 2D DMDA object with star-type
>stencils. For a typical local calculation, I only need to access ghost values
>from two of the four directions at a time. For example, I'd like access to
>ghost
>values in the South and East directions, but not in the North or West
>directions. Communicating North and West data would seem to be wasting
>bandwidth. Is there any way to accomplish this?
>
> Greg,
>
> There is not anything built in. Here is what I suggest:
>
>1) write your application code not worrying about the fact that the
>DMGlobalToLocalBegin/End() is moving values you don't need.
>
>2) when your code is running correctly for your problem and giving useful
>results if the communication times are impacting how long it takes to run you
>can provide a custom communication pattern. It would involve little
>additional coding essentially taking DMSetUp_DA_2D() which creates the list
>of ghost points and removing the unneeded ghost points. But it would be
>premature to do this optimization until you have a full working application
>code.
>
> Barry
>
>>
>> Thanks,
>> Greg
>
>
