<div dir="ltr"><div>Thank you for the reply. </div><div><br></div><div>I think it can be more helpful for me if the attached sample code (DMInterpolation_Mod.tar) could be checked by you. If you run the sample code, basically, you would get "VertexField_Map_from_Cell.vtu" file which displays a solution vector field defined on each vertex, which is mapped from another solution field defined on each cell-centroid. The vertex solution field in the vtu file should match with "x-coordinate" value in the same file. Basically, the attached code tries to reproduce vertex's x-coordinate value using cell-centroid's x-coordinate value by means of finite-element space mapping between Q0 and Q1.</div><div>From the vtu file, it is obvious that at the physical boundaries (left, right, top, and bottom) x-coordinate value is not properly mapped from cell-centroid, whereas interior vertex's solution seems okay. What I do not understand is why the boundary vertices cannot have properly mapped coordinate values? I believe I am doing something wrong and I was suspicious about the ghost cell, which I do not have. But your comment seems to say that the problem is not related to the ghost cell. What am I doing wrong?<br></div><div><br></div><div><div>Does your section mark these unknowns as constrained?</div>--> Yes, as shown in the code, I defined one section for each dmplex, one for vertex and one for cell, respectively, with 1-dof for each (See code line from 91 to 124).</div><div><br></div><div><div>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.</div><div>--> Yes, you are correct. Now I do not have zero value at the physical boundaries, however, it is still not proper value and seems underscaled, compared to the proper answer (i.e., compared with the properly mapped interior values).</div><div><br></div><div>Thanks,</div><div><br></div></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 dir="ltr"><br>On Sun, Aug 28, 2022 at 12:11 PM Mike Michell <<a href="mailto:mi.mike1021@gmail.com" target="_blank">mi.mike1021@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 reply.</div><div><br></div><div><div><b>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?</b></div><div>--> 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</div></div></div></blockquote><div><br></div><div>Does your section mark these unknowns as constrained?</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><div> 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.</div></div></div></blockquote><div><br></div><div>As I replied, I think this is not true.</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><div>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?</div></div></div></blockquote><div><br></div><div>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.</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><div> 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. </div></div><div dir="ltr"><br></div><div>Thanks,</div><br><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 dir="ltr"><br>On Sun, Aug 28, 2022 at 8:51 AM Mike Michell <<a href="mailto:mi.mike1021@gmail.com" target="_blank">mi.mike1021@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, thank you for the reply. </div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>It needs a custom Fortran wrapper to check for the NULL input from Fortran.</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>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?</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Did I understand your question, or is it about something else?</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>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?</div></div></blockquote><div><br></div><div>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.</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>Thanks,</div><br><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 dir="ltr"><br>On Thu, Aug 25, 2022 at 7:12 PM Mike Michell <<a href="mailto:mi.mike1021@gmail.com" target="_blank">mi.mike1021@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">Hi, this is a duplication of <div><a href="https://lists.mcs.anl.gov/pipermail/petsc-users/2022-August/046746.html" target="_blank">https://lists.mcs.anl.gov/pipermail/petsc-users/2022-August/046746.html</a> <div>for in-depth question.<br></div><div><br></div><div>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. <br><br>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?<br></div></div></div></blockquote><div><br></div><div>Sure, I am looking at it.</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><div>Thanks,<br></div></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 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 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>