Something like
DMDASetComputeGhostBoundary(DM dm, s(DM,Vec,Vec,void*),d(void*))
where
s(DM dm, Vec g, Vec l, void*ctx) {
User code that fills in appropriate places in l.
d(void* ctx) {
Optional: Destroys optional user context when DM is destroyed.
}
and s() gets called inside of DMGlobalToLocalEnd() just before it returns?
Yes, this seems doable. But I note that you can simply perform your s()
function on the local vector immediately after you call DMGlobalToLocalEnd()
and get the same affect.
Barry
> On Aug 15, 2022, at 4:02 AM, David Scott <[email protected]> wrote:
>
>
>
> On 12/08/2022 18:15, Matthew Knepley wrote:
>> This email was sent to you by someone outside the University.
>> You should only click on links or attachments if you are certain that the
>> email is genuine and the content is safe.
>> On Fri, Aug 12, 2022 at 9:27 AM David Scott <[email protected]
>> <mailto:[email protected]>> wrote:
>> On 12/08/2022 11:26, Matthew Knepley wrote:
>>> This email was sent to you by someone outside the University.
>>> You should only click on links or attachments if you are certain that the
>>> email is genuine and the content is safe.
>>> On Fri, Aug 12, 2022 at 2:21 AM Quynh Nguyen <[email protected]
>>> <mailto:[email protected]>> wrote:
>>> Dear petsc developers and users,
>>>
>>> I am a new petsc user ^_^.
>>> I have some questions about using DMDA_BOUNDARY_GHOSTED.
>>>
>>> 1. I have 2D Poisson code with domain (nx, ny), and I used
>>> DMDA_BOUNDARY_NONE, then the size of the matrix is (nx*ny)X(nx*ny). what is
>>> the size of the matrix if I used DMDA_BOUNDARY_GHOSTED? is it the same
>>> size as DMDA_BOUNDARY_NONE?
>>>
>>> Yes, the matrix should be the same size, but local vectors have extra ghost
>>> node slots.
>>>
>>> 2. if the matrix size of DMDA_BOUNDARY_GHOSTED isn't the same as
>>> DMDA_BOUNDARY_NONE, how i can view the matrix including ghost points? I ask
>>> this one because I used MatView(P, PETSC_VIEWER_STDOUT_WORLD) to show the
>>> matrix but excluded ghost points.
>>>
>>> Ghost nodes are there so that stencil operations on local vectors work at
>>> boundaries. You fill in the slots with boundary information.
>>>
>> I can see how this works if you are writing your own solver but can it be
>> used with a KSP? In the case of periodic boundary conditions the boundary
>> values are "filled in" for you by PETSc. Is there any way for a user to
>> supply boundary information to a PETSc solver when using
>> DMDA_BOUNDARY_GHOSTED?
>>
>> Right now, there is not. This is mainly due to the lack of consensus for
>> boundary condition specification. Periodic conditions are simple in this
>> respect.
>>
>> For example, Plex has such a thing
>>
>> https://petsc.org/main/docs/manualpages/DM/DMAddBoundary/
>> <https://petsc.org/main/docs/manualpages/DM/DMAddBoundary/>
>>
>> that can be used to fill in these constrained spots
>>
>> https://petsc.org/main/docs/manualpages/DMPLEX/DMPlexInsertBoundaryValues/
>> <https://petsc.org/main/docs/manualpages/DMPLEX/DMPlexInsertBoundaryValues/>
>>
>> But there have been many complaints about this interface (and I suspect any
>> interface we choose).
>>
>> Maybe there is something that we could write that would make it easier for
>> you with DMDA?
>>
> The way I had imagined it working was that for each dimension the user could
> register a function to be to be called at the start of every iteration (in a
> similar fashion to adding a monitor). Not all of the dimensions would have to
> be specified as DMDA_BOUNDARY_GHOSTED and thus require a function to be
> registered. This function would have access to the DMDA and the local vector
> so it could determine if ghost locations were present and, if so, set
> appropriate values. Does this make sense?
>
> Thanks,
>
> David
>
>> Thanks,
>>
>> Matt
>>
>> Thanks,
>>
>> David
>>
>>> Thanks,
>>>
>>> Matt
>>>
>>> I hope someone can explain my wonder :)
>>>
>>> P/S: maybe, those question is simple and a bit stupid ^_^.
>>>
>>> Have a nice day,
>>>
>>> --
>>> Quynh Nguyen
>>> Graduate student, Ocean Engineering.
>>> School of Naval Architecture and Ocean Engineering, University of Ulsan.
>>> -----------------------------------------------------------------------------------------
>>> Mobile: (+82) 010-9394-5595
>>> Email: [email protected] <mailto:[email protected]>;
>>> [email protected] <mailto:[email protected]>
>>>
>>> --
>>> 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
>>>
>>> https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
>>
>> The University of Edinburgh is a charitable body, registered in Scotland,
>> with registration number SC005336. Is e buidheann carthannais a th’ ann an
>> Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
>>
>>
>> --
>> 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
>>
>> https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
>
