[petsc-users] Implementing periodicity using DMPlex

Tue Jun 23 13:43:13 CDT 2020

On Sat, Jun 20, 2020 at 2:41 AM Matthew Knepley <knepley at gmail.com> wrote:

> On Thu, Jun 18, 2020 at 1:20 PM Shashwat Tiwari <shaswat121994 at gmail.com>
> wrote:
>
>> Thank you for the help. I followed your suggestion and removed the
>> "DMPlexConstructGhostCells" function and now I am using a gmsh generated
>> mesh with periodicity in both directions, and distributing the mesh with 1
>> level of overlap. I can see that the periodic faces now have two
>> neighbouring cells on the opposite side of the domain which I can use to
>> get the periodic cell values using "DMGlobalToLocal" without the need to
>> construct ghost cells. There are two main issues that I am facing now,
>> regarding geometric information needed for implementing periodic bc.
>>
>> One, I may need the centroid of periodic counterpart of a cell which is
>> possible to get from a "ghost" cell created on the periodic face, and
>> containing the solution data from periodic counterpart. But now, I would
>> need to shift the coordinates of the neighbouring cell accordingly. If you
>> see the sample output given below along with the screenshot of the sample
>> 2D mesh that I have used (please find attached), while reconstructing the
>> left and right solution values on face 32 for a second order scheme, I need
>> the centroid of a ghost cell on left side of the face which is at (x, y) =
>> (-1.25, 8.75). I wanted to know if there is some way to get these shifted
>> "ghost" coordinates directly from the geometric information obtained using
>> "PetscFV" class. Kindly let me know if you have some suggestions regarding
>> this.
>>
>
> I do not completely understand the question. However, I think you want
> something like
>
>
> https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DM/DMLocalizeCoordinate.html
>
> There are many variants of this functionality.
>
This function seems to be for the purpose of shifting the coordinates which
are outside the domain, to inside the domain limit. I want to shift the
coordinates of the periodic neighbor of a cell, which is a cell inside the
domain. I think I can manage to do that myself manually without much
complications.

Sample Output:
>>
>> face: 32, centroid = 0.000000, 8.750000, normal = 2.500000, -0.000000
>> support[0] = 0, cent = 1.250000, 8.750000, area = 6.250000
>> support[1] = 3, cent = 8.750000, 8.750000, area = 6.250000
>>
>> face: 33, centroid = 1.250000, 7.500000, normal = -0.000000, -2.500000
>> support[0] = 0, cent = 1.250000, 8.750000, area = 6.250000
>> support[1] = 4, cent = 1.250000, 6.250000, area = 6.250000
>>
>> Second, the face normals of the periodic faces obtained using the face
>> geometry data from "DMPlexGetDataFVM" function seem to be in the wrong
>> direction i.e., from the right cell "support[1]" to the left cell
>> "support[0]", while the other faces have the opposite direction. For face:
>> 32, left cell is 0 and the right cell is 3, but, the normal points the
>> opposite way (cell 3 would be on the left side of cell 0 on periodic
>> boundary), while, for face: 33 which is an interior face, the normal
>> direction is from left to right cell.
>>
>
> This should be easy to check. The strange thing is that if this were
> broken, you would expect other examples to fail.
>
I am actually unable to get these values right. The normals seem to be in
the opposite direction for all the periodic faces and length of some faces
gets multiplied by a factor of three. Were you able to look at this? If so,
kindly let me know how I can resolve this issue.

Regards,
Shashwat

>
>
>> Also, I am getting incorrect normal values for some of the faces
>> (including some interior faces). Here is a sample output of the same:
>>
>> face: 59, centroid = 3.750000, 2.500000, normal = 0.000000, -7.500000
>> support[0] = 11, cent = 8.750000, 3.750000, area = 6.250000
>> support[1] = 15, cent = 8.750000, 1.250000, area = 6.250000
>>
>> this face has the correct direction (from 11 to 15), but the value is
>> wrong (all the faces are 2.5 units). This problem does not occur when I
>> ignore periodicity by setting -dm_plex_gmsh_periodic to 0.
>>
>> These issues occur regardless of the number of processes. I am attaching
>> the test code that I am using along with the gmsh file for your reference.
>> Please suggest to me, what might be the issue here.
>>
>
> I will take a look.
>
>   Thanks,
>
>     Matt
>
>
>> Regards,
>> Shashwat
>>
>>
>> On Mon, Jun 15, 2020 at 2:54 PM Stefano Zampini <
>> stefano.zampini at gmail.com> wrote:
>>
>>> It is enough if you use DMPlexDistribute with 1 level of overlap, set
>>> the local section for your dofs,  and call DMGlobalToLocal . The local
>>> vector will contain data for what you call “ghost” cells. I call them
>>> “not-owned’ cells.
>>>
>>> On Jun 15, 2020, at 12:09 PM, Shashwat Tiwari <shaswat121994 at gmail.com>
>>> wrote:
>>>
>>> The way I'm trying to implement periodic bc is, when I loop over the
>>> boundary faces, say, on the left boundary of the domain to compute flux and
>>> residual, I need solution values from the two cells neighbouring the face,
>>> i.e. the left cell and the right cell (the face normal pointing from the
>>> left cell to the right cell and the right cell being a boundary ghost cell
>>> for boundary faces). For the boundary to be periodic, I need the value that
>>> I get from the right cell (boundary ghost cell) to be the solution value at
>>> its periodic counterpart, i.e. the solution value at left cell of the face
>>> on right boundary of the domain in this case. My question is how do I
>>> update the value at a boundary ghost cell with the value at the real cell
>>> which is its periodic counterpart from the other side of the domain. Is
>>> there some kind of mapping of the boundary ghost cells to their
>>> corresponding real cells which I can use to update the solution values at
>>> ghost cells?
>>>
>>> Regards,
>>> Shashwat
>>>
>>> On Sun, Jun 14, 2020 at 5:11 AM Matthew Knepley <knepley at gmail.com>
>>> wrote:
>>>
>>>> On Fri, Jun 12, 2020 at 3:19 PM Shashwat Tiwari <
>>>> shaswat121994 at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>> I am writing a first order 2D solver for unstructured grids with
>>>>> periodic boundaries using DMPlex. After generating the mesh, I use
>>>>> "DMSetPeriodicity" function to set periodicity in both directions. After
>>>>> which I partition the mesh (DMPlexDistribute), construct ghost cells
>>>>> (DMPlexConstructGhostCells),
>>>>>
>>>>
>>>> These ghost cells are for FVM boundary conditions. If you want cells to
>>>> be shared across parallel partitions, then you want to give overlap=1
>>>> to DMPlexDIstribute(). Is that what you want?
>>>>
>>>>   Thanks,
>>>>
>>>>      Matt
>>>>
>>>>
>>>>> create a section, and set some initial values in the global vector.
>>>>> Then I use "VecGhostUpdateBegin" to start updating the boundary ghost cell
>>>>> values, but, I get the following error in case I use multiple processors:
>>>>>
>>>>> [0]PETSC ERROR: Invalid argument
>>>>> [0]PETSC ERROR: Vector is not ghosted
>>>>> [0]PETSC ERROR: See
>>>>> https://www.mcs.anl.gov/petsc/documentation/faq.html for trouble
>>>>> shooting.
>>>>>
>>>>> if I run with a single process, there is no error but the values
>>>>> remain empty (zero) and are not updated. Kindly let me know, if I am
>>>>> missing some crucial step before I can update the ghost values in order to
>>>>> implement the periodic bc, or if there is any other approach to achieve it.
>>>>> I am attaching a small code to demonstrate the issue for your reference.
>>>>>
>>>>> Regards,
>>>>> Shashwat
>>>>>
>>>>
>>>>
>>>> --
>>>> 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/>
>>>>
>>>
>>>
>
> --
> 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/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20200624/09cc9e97/attachment.html>