On Sun, Aug 28, 2022 at 12:11 PM Mike Michell <mi.mike1...@gmail.com> wrote:
> Thank you for the reply. > > *I cannot quite understand. Are you saying that you have inhomogeneous > Dirichlet conditions on the boundary, and a 0 guess in the interior, and > you get all zeros from interpolation? Yes, we have no way of getting > boundary values into the operator. You could conceivably make an operator > that mapped between local vectors, but it is hard to see why you would want > this. In the solver, we usually just care about the unknowns we are > solving for. Did I understand your question, or is it about something else?* > --> It is not imposing a physical boundary condition (Dirichlet condition > for example), but my solver needs to import an external solution vector > field resolved to each cell-centroid, then I need to map it to a vertex > field in which my solver is resolved for solving governing equations. Then, > my code solves its equations. After my solver is done solving the > equations, the vertex field should be re-map into cell-field and then push > back the cell field to the external code. With this context, I have zero > values returned at the vertices on the physical boundaries > Does your section mark these unknowns as constrained? > if I try mapping from cell-center to vertex field without having ghost > cell layers inside physical boundaries. For interior vertices, I get > reasonable mapped values, although the mapping accuracy seems to be able to > be improved as I mentioned in the earlier email. > As I replied, I think this is not true. > If dmplex for cell-center field would be defined to have ghost cell layer, > and fill it (it meant import ghost cell values as well from the external > code), and map it to vertex-field, can it be possible to fill vertex points > on the physical boundaries? > You should not get 0 unless you constrained these variables in the section. If not, you should see it use the constant values in the cell. Thanks, Matt > I was trying to test this strategy, but it > seems DMPlexComputeCellGeometryFVM() gives NaN values if dmplex has ghost > cell by calling DMPlexConstructGhostCells(). In detail, > DMPlexComputeCellGeometryFVM() gives zero area for each cell, and returns > NaN values for cell centroids and normals for the ghost cells. > > Thanks, > > >> On Sun, Aug 28, 2022 at 8:51 AM Mike Michell <mi.mike1...@gmail.com> >> wrote: >> >>> Hi, thank you for the reply. >>> >>> I was able to manage mapping from cell-center to vertex. Basically, in >>> Fortran, it seems DMCreateInterpolation() requires the optional scaling >>> vector as a mandatory argument, which is strange. >>> >> >> It needs a custom Fortran wrapper to check for the NULL input from >> Fortran. >> >> >>> My dmplex has zero overlap layer over the procs, and there is no ghost >>> cell inside physical boundary. In this case, it seems mapping between cell >>> center to vertex returns zero (in case the global cell vector initialized >>> to zero) value at the nodes, which are located at physical boundary. To >>> manage this problem, is it mandatory to have ghost cells. Is this correct >>> understanding? >>> >> >> I cannot quite understand. Are you saying that you have inhomogeneous >> Dirichlet conditions on the boundary, and a 0 guess in the interior, and >> you get all zeros from interpolation? Yes, we have no way of getting >> boundary values into the operator. You could conceivably make an operator >> that mapped between local vectors, but it is hard to see why you would want >> this. In the solver, we usually just care about the unknowns we are >> solving for. >> >> Did I understand your question, or is it about something else? >> >> >>> Also, my mapping accuracy itself seems to be improved. For simple test, >>> cell-center's x-coordinate value of each cell mapped to node and printed to >>> the vertex field as .vtu format, and the mapped x-vertex-coordinate is >>> quite different with the actual nodal coordinate values what PETSc >>> intrinsically provides through DMGetCoordinatesLocal(). I believe I am >>> doing something wrong, probably arguments in PetscFECreateLagrange() can >>> improve the mapping accuracy in finite-element space? >>> >> >> Yes, a cellwise field is much less accurate than a linear field. Pushing >> the values up to a linear field does not make them more accurate. >> >> Thanks, >> >> Matt >> >> >>> Thanks, >>> >>> >>>> On Thu, Aug 25, 2022 at 7:12 PM Mike Michell <mi.mike1...@gmail.com> >>>> wrote: >>>> >>>>> Hi, this is a duplication of >>>>> https://lists.mcs.anl.gov/pipermail/petsc-users/2022-August/046746.html >>>>> >>>>> for in-depth question. >>>>> >>>>> I wrote a short code as attached to test interpolation between two >>>>> DMPlex objects. Goal is to map solution field defined on >>>>> cell-centroid(DMPlex-1) into vertex(DMPlex-2) field or vice versa. >>>>> >>>>> Basically, DMCreateInterpolation() fails in the example code and it >>>>> was not allowed to get useful error messages. The DMPlex is created by >>>>> loading a 2D square box in Gmsh. Can I get some comments on that? >>>>> >>>> >>>> Sure, I am looking at it. >>>> >>>> Thanks, >>>> >>>> Matt >>>> >>>> >>>>> Thanks, >>>>> >>>> >>>> >>>> -- >>>> 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/> >> > -- 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/>