[petsc-users] DMAdaptLabel with triangle mesh

Tue Sep 1 01:24:23 CDT 2020

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 ?

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/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20200901/42195ecb/attachment.html>