[petsc-users] DMAdaptLabel with triangle mesh

Tue Sep 1 14:13:10 CDT 2020

On Tue, Sep 1, 2020 at 2:24 AM Thibault Bridel-Bertomeu <
thibault.bridelbertomeu at gmail.com> wrote:

> Hi everyone, hi Matt,
>
> Le lun. 31 août 2020 à 22:03, Matthew Knepley <knepley at gmail.com> a
> écrit :
>
>> 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.
>>
>
> Oh really, only the one ? Okay okay, I guess I was too optimistic ! I'll
> look into Pragmatic even though it is in dev, maybe it'll be enough for
> what I wanna do for now.
> By the way, talking about things that get in the way, should I open an
> issue on the gitlab regarding Triangle not ignoring the ghost cells, would
> that be easier for you guys ?
>

I think it s is fixed: https://gitlab.com/petsc/petsc/-/merge_requests/3123

  Thanks

    Matt

> Thanks & have a great day,
>
> Thibault
>
>
>
>>   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/>
>>
>

-- 
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/20200901/435d8ff3/attachment.html>