[petsc-users] DMAdaptLabel with triangle mesh

Mon Aug 31 15:03:23 CDT 2020

On Mon, Aug 31, 2020 at 4:00 PM Thibault Bridel-Bertomeu <
thibault.bridelbertomeu at gmail.com> wrote:

>
>
> Le lun. 31 août 2020 à 20:35, Matthew Knepley <knepley at gmail.com> a
> écrit :
>
>> On Mon, Aug 31, 2020 at 9:45 AM Thibault Bridel-Bertomeu <
>> thibault.bridelbertomeu at gmail.com> wrote:
>>
>>> Hi Matt,
>>>
>>> OK so I tried to replicate the problem starting from one of the tests in
>>> PETSc repo.
>>> I found
>>> https://gitlab.com/petsc/petsc/-/blob/master/src/dm/impls/plex/tests/ex20.c that
>>> actually uses DMAdaptLabel.
>>> Just add
>>>
>>> {
>>>
>>>  DM <https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DM/DM.html#DM> gdm;
>>>
>>>
>>>
>>>  DMPlexConstructGhostCells <https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DMPLEX/DMPlexConstructGhostCells.html#DMPlexConstructGhostCells>(dm, NULL, NULL, &gdm);
>>>
>>>  DMDestroy <https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DM/DMDestroy.html#DMDestroy>(&dm);
>>>
>>>  dm   = gdm;
>>>
>>> }
>>>
>>> after line 24 where the box mesh is generated. Then compile and run with ex20 -dim 2.
>>>
>>> It should tell you that Triangle 18 has an invalid vertex index.
>>>
>>> That's the minimal example that I found that replicates the problem.
>>>
>>> Ah, okay. p4est knows to discard the ghost cells. I can add that to
>> Triangle.
>>
>
> I thought it was something like that, seeing what addition of code
> triggers the problem.
> Thanks for adding the treatment to Triangle !
>
>> Regarding the serial character of the technique, I tried with a distributed mesh and it works.
>>>
>>> Hmm, it can't work. Maybe it appears to work. Triangle knows nothing
>> about parallelism. So this must be feeding the local mesh to triangle and
>> replacing it by
>> a refined mesh, but the parallel boundaries will not be correct, and
>> might not even match up.
>>
>
> Ok, yea, it appears to work. When asked to refine from scratch, not from
> AdaptLabel but with a -dm_refine order, the mesh is funky as if it was
> entirely re-made and the previous mesh thrown away.
> Can you think of a way where each processor would be able to call on
> Triangle on it’s own, with its own piece of mesh and maybe the surrounding
> ghost cells ? I imagine it could work for parallel refining of triangular
> meshes, couldn’t it ?
>

It turns out that his is a very hairy problem. That is why almost no
parallel refinement packages exist. To my knowledge, this is only one:
Pragmatic. We support that package, but
it is in development, and we really need to update our interface. I am
working on it, but too much stuff gets in the way.

  Thanks,

      Matt

> Thanks for your replies,
> Have a great afternoon/evening !
>
> Thibault
>
>
>>   Thanks,
>>
>>      Matt
>>
>>> So do you mean that intrinsically it gathers all the cells on the master proc before proceeding to the coarsening & refinement and only then broadcast the info back to the other processors ?
>>>
>>> Thanks,
>>>
>>> Thibault
>>>
>>> Le lun. 31 août 2020 à 12:55, Matthew Knepley <knepley at gmail.com> a
>>> écrit :
>>>
>>>> On Mon, Aug 31, 2020 at 5:34 AM Thibault Bridel-Bertomeu <
>>>> thibault.bridelbertomeu at gmail.com> wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> I have recently been playing around with the AMR capabilities embedded
>>>>> in PETSc for quad meshes using p4est. Based on the TS tutorial ex11, I was
>>>>> able to incorporate the AMR into a pre-existing code with different metrics
>>>>> for the adaptation process.
>>>>> Now I would like to do something similar using tri meshes. I read that
>>>>> compiling PETSc with Triangle (in 2D and Tetgen for 3D) gives access to
>>>>> refinement and coarsening capabilities on triangular meshes.When I try to
>>>>> execute the code with a triangular mesh (that i manipulate as a DMPLEX), it
>>>>> yields "Triangle 1700 has an invalid vertex index" when trying to adapt the
>>>>> mesh (the initial mesh indeed has 1700 cells). From what i could tell, it
>>>>> comes from the reconstruct method called by the triangulate method of
>>>>> triangle.c, the latter being called by either
>>>>> *DMPlexGenerate_Triangle *or *DMPlexRefine_Triangle *in PETSc, I
>>>>> cannot be sure.
>>>>>
>>>>> In substance, the code is the same as in ex11.c and the crash occurs
>>>>> in the first adaptation pass, i.e. an equivalent in ex11 is that it crashes
>>>>> after the SetInitialCondition in the first if (useAMR) located line 1835
>>>>> when it calls adaptToleranceFVM (which I copied basically so the code is
>>>>> the same).
>>>>>
>>>>> Is the automatic mesh refinement feature on tri meshes supposed to
>>>>> work or am I trying something that has not been completed yet ?
>>>>>
>>>>
>>>> It is supposed to work, and does for some tests in the library. I
>>>> stopped using it because it is inherently serial and it is isotropic.
>>>> However, it should be fixed.
>>>> Is there something I can run to help me track down the problem?
>>>>
>>>>   Thanks,
>>>>
>>>>      Matt
>>>>
>>>>
>>>>> Thank you very much for your help, as always.
>>>>>
>>>>> Thibault Bridel-Bertomeu
>>>>> —
>>>>> Eng, MSc, PhD
>>>>> Research Engineer
>>>>> CEA/CESTA
>>>>> 33114 LE BARP
>>>>> Tel.: (+33)557046924
>>>>> Mob.: (+33)611025322
>>>>> Mail: thibault.bridelbertomeu at gmail.com
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> 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/>
>>
>>
>> --
> Thibault Bridel-Bertomeu
> —
> Eng, MSc, PhD
> Research Engineer
> CEA/CESTA
> 33114 LE BARP
> Tel.: (+33)557046924
> Mob.: (+33)611025322
> Mail: thibault.bridelbertomeu at gmail.com
>

-- 
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/20200831/8ca8f254/attachment.html>