[petsc-users] DMAdaptLabel with triangle mesh

Tue Sep 1 14:24:13 CDT 2020

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

> Hi Matthew,
>
> So I turned the pages of the User guide real quick and the only reference
> I found to Pragmatic was in DMAdaptMetric. It says it is based on a
> vertex-based metric, but I could not find any more information regarding
> the characteristics of the expected metric ... Would you by any chance have
> more documentation or maybe a test/tutorial/example that builds such a
> metric and calls DMAdaptMetric ?
>

There are tests:
https://gitlab.com/petsc/petsc/-/blob/master/src/dm/impls/plex/tests/ex19.c
but not much explanation. The input is actually the metric tensor at the
vertices. You can see
me making representative things in the example.

  Thanks,

     Matt

> Thanks,
>
> Thibault
>
> Le mar. 1 sept. 2020 à 08:24, Thibault Bridel-Bertomeu <
> thibault.bridelbertomeu at gmail.com> a écrit :
>
>> 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/>
>>>
>>

-- 
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/f155eb3c/attachment.html>