[petsc-users] DMPlex Interpolation

[Matthew Knepley]

On Sun, Aug 28, 2022 at 12:11 PM Mike Michell <mi.mike1021 at 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.mike1021 at 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.mike1021 at 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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20220828/9d64263c/attachment.html>