<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 20, 2020 at 2:41 AM Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Thu, Jun 18, 2020 at 1:20 PM Shashwat Tiwari <<a href="mailto:shaswat121994@gmail.com" target="_blank">shaswat121994@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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. <br></div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>I do not completely understand the question. However, I think you want something like</div><div><br></div><div> <a href="https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DM/DMLocalizeCoordinate.html" target="_blank">https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DM/DMLocalizeCoordinate.html</a></div><div><br></div><div>There are many variants of this functionality.</div></div></div></blockquote><div>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. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Sample Output:</div><div><br></div><div><div>face: 32, centroid = 0.000000, 8.750000, normal = 2.500000, -0.000000<br>support[0] = 0, cent = 1.250000, 8.750000, area = 6.250000<br>support[1] = 3, cent = 8.750000, 8.750000, area = 6.250000<br><br>face: 33, centroid = 1.250000, 7.500000, normal = -0.000000, -2.500000<br>support[0] = 0, cent = 1.250000, 8.750000, area = 6.250000<br>support[1] = 4, cent = 1.250000, 6.250000, area = 6.250000<br></div></div><div><br></div><div>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. </div></div></blockquote><div><br></div><div>This should be easy to check. The strange thing is that if this were broken, you would expect other examples to fail.</div></div></div></blockquote><div>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. <br></div><div><br></div><div>Regards,</div><div>Shashwat<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Also, I am
getting incorrect normal values for some of the faces (including some
interior faces). Here is a sample output of the same:</div><div><br></div><div>face: 59, centroid = 3.750000, 2.500000, normal = 0.000000, -7.500000<br>support[0] = 11, cent = 8.750000, 3.750000, area = 6.250000<br>support[1] = 15, cent = 8.750000, 1.250000, area = 6.250000</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>I will take a look.</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Regards, <br></div><div>Shashwat</div></div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 15, 2020 at 2:54 PM Stefano Zampini <<a href="mailto:stefano.zampini@gmail.com" target="_blank">stefano.zampini@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>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.<br><div><br><blockquote type="cite"><div>On Jun 15, 2020, at 12:09 PM, Shashwat Tiwari <<a href="mailto:shaswat121994@gmail.com" target="_blank">shaswat121994@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div>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? <br><div><br></div><div>Regards,</div><div>Shashwat<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 14, 2020 at 5:11 AM Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Fri, Jun 12, 2020 at 3:19 PM Shashwat Tiwari <<a href="mailto:shaswat121994@gmail.com" target="_blank">shaswat121994@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi, <br></div><div>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),</div></div></blockquote><div><br></div><div>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</div><div>to DMPlexDIstribute(). Is that what you want?</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> 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:</div><div><br></div><div>[0]PETSC ERROR: Invalid argument<br>[0]PETSC ERROR: Vector is not ghosted<br>[0]PETSC ERROR: See <a href="https://www.mcs.anl.gov/petsc/documentation/faq.html" target="_blank">https://www.mcs.anl.gov/petsc/documentation/faq.html</a> for trouble shooting.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Shashwat<br></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div>
</div></blockquote></div><br></div></div></blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div></div>