[petsc-users] Periodic domains in DMPlex / petsc4py

Wed Dec 12 09:24:49 CST 2018

Il giorno mer 12 dic 2018 alle ore 17:45 Artur Palha Da Silva Clérigo - LR <
A.PalhaDaSilvaClerigo at tudelft.nl> ha scritto:

>
>
> On 12 Dec 2018, at 15:26, Stefano Zampini <stefano.zampini at gmail.com>
> wrote:
>
> What do you mean by "I always get the first numbering”?
>
>
> I mean that if I use as input a periodic and a non-periodic mesh I get the
> following numbering in both cases:
>
> 1                3                5
>>> X-------------X-------------X
>>> |                  |                 |
>>> |                  |                 |
>>> |                  |                 |
>>> X-------------X-------------X
>>>
>> 0                2                 4
>>>
>>
> That is, the numbering of the degrees of freedom is ignoring the
> periodicity in the mesh file.
>
>
> I understand you are using GMSH right? To have PETSc read the periodic
> section of the .msh file, you need to pass -dm_plex_gmsh_periodic
>
>
> I am not doing that. For an executable I see that you can do this by
> passing the -dm_plex_gmsh_periodic switch. Is there any way of doing that?
> For example using PetscOptionsSetValue? I ask this because I am using
> petsc4py so I do not see how to pass the -dm_plex_gmsh_periodic switch in
> python.
>

$ python your_petsc_based.py -dm_plex_gmsh_periodic

>
> Note that DMLocalizeCoordinates will localize coordinates ONLY if you use
> DMSetPerioidicity(), which is done in the GMSH reader
>
>
> Could you point me to an example of this? I do not see how to use
> DMSetPeriodicity() for a general domain.
>
>
periodicity is a horrible beast. I would not recommend playing with it.
They way it is done in DMPlex, is to have a coordinate section with dofs
not only at mesgh vertices, but also located at selected cells (the cells
that touch the periodic boundary).
DMSetPeriodicity is a convenient API to tell PETSc that the mesh has some
periodicity in it, so that PETSc can take the correct decision when it
comes to do mesh refinement for examples
However, it is responsibility of the user to construct the proper localized
coordinates, unless you have a simple mesh like the BoxMesh constructed
with DMPlexCreateBoxMesh.

As I said, all of this is done automatically when you load a periodic mesh
from GMSH

> Thank you.
>
> -artur palha
>
>
> Il giorno mer 12 dic 2018 alle ore 17:17 Artur Palha Da Silva Clérigo - LR
> via petsc-users <petsc-users at mcs.anl.gov> ha scritto:
>
>>
>>
>> On 12 Dec 2018, at 15:14, Matthew Knepley <knepley at gmail.com> wrote:
>>
>> On Wed, Dec 12, 2018 at 9:12 AM Artur Palha Da Silva Clérigo - LR <
>> A.PalhaDaSilvaClerigo at tudelft.nl> wrote:
>>
>>> Dear Matt,
>>>
>>> Thank you for your quick reply. As for your question: "why would there
>>> be a difference? They should be numbered in the same way.”
>>>
>>> I see the degrees of freedom living on the periodic domain as the ones
>>> living at boundaries between interior elements. This is what I expect for
>>> non-periodic domain for nodal scalar field:
>>>
>>> Non-periodic:
>>>
>>> 1                3                5
>>> X-------------X-------------X
>>> |                  |                 |
>>> |                  |                 |
>>> |                  |                 |
>>> X-------------X-------------X
>>> 0                2                 4
>>>
>>> Periodic (vertical boundaries, topologically, the domain is a cylinder)
>>>
>>> 1                3                1
>>> X-------------X-------------X
>>> |                  |                 |
>>> |                  |                 |
>>> |                  |                 |
>>> X-------------X-------------X
>>> 0                2                 0
>>>
>>> This is not the expected behaviour?
>>>
>>
>> What I mean is that each vertex in the periodic domain gets 1 dof. Same
>> procedure as non-periodic.
>> We do not duplicate vertices or anything like that.
>>
>>
>> Yes, I agree. That happens yes. What I meant was that for both the
>> periodic and non-periodic case I always get the first numbering. Is this
>> because I miss DMLocalizeCoordinates?
>>
>>
>>
>>
>>   Thanks,
>>
>>     Matt
>>
>>
>>> Once again thank you for your help.
>>>
>>> -artur palha
>>>
>>> On 12 Dec 2018, at 15:04, Matthew Knepley <knepley at gmail.com> wrote:
>>>
>>> On Wed, Dec 12, 2018 at 9:01 AM Artur Palha Da Silva Clérigo - LR via
>>> petsc-users <petsc-users at mcs.anl.gov> wrote:
>>>
>>>> Dear All,
>>>>
>>>> I having been trying to add periodic domain functionality to my code. I
>>>> am able to generate a periodic mesh with gmsh and load it using dmplex. The
>>>> problem is that I am unable to have a numbering of the degrees of freedom
>>>> that reflects the periodicity (they are numbered as if there was no
>>>> periodicity).
>>>>
>>>
>>> Why would there be a difference? They should be numbered in the same way.
>>>
>>>
>>>> I read this thread:
>>>> https://lists.mcs.anl.gov/mailman/htdig/petsc-users/2018-October/036539.html
>>>>
>>>> There it is mentioned that DMLocalizeCoordinates is required after
>>>> loading the mesh.
>>>>
>>>
>>> Yes, this makes cell-wise coordinates, which have a jump at the periodic
>>> boundary.
>>>
>>>
>>>> My questions are the following:
>>>>
>>>> 1. Is it correct that I need to run DMLocalizeCoordinates on my DM?
>>>>
>>>
>>> Yes.
>>>
>>>
>>>> 2. I am currently using petsc4py but I am unable to find
>>>> DMLocalizeCoordinates. Is this functionality missing or is there an
>>>> alternative to it?\
>>>>
>>>
>>> Its possible no wrapper has been written for this yet. Lisandro, is it
>>> missing? (I am at a meeting, or I would check).
>>>
>>>   Thanks,
>>>
>>>     Matt
>>>
>>>
>>>> Thank you for your time.
>>>>
>>>> Kind regards,
>>>>
>>>> -artur palha
>>>>
>>>
>>>
>>> --
>>> 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/>
>>
>>
>>
>
> --
> Stefano
>
>
>

-- 
Stefano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20181212/282b86e6/attachment.html>