[petsc-users] DMPlex Interpolation
Mike Michell
mi.mike1021 at gmail.com
Sun Aug 28 11:11:32 CDT 2022
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 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.
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? 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/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20220828/162700ca/attachment-0001.html>
More information about the petsc-users
mailing list