[petsc-users] DMAdaptLabel with triangle mesh

Thibault Bridel-Bertomeu thibault.bridelbertomeu at gmail.com
Mon Aug 31 15:00:41 CDT 2020


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 ?

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


More information about the petsc-users mailing list