[petsc-users] DMAdaptLabel with triangle mesh

Wed Sep 2 10:52:09 CDT 2020

Thank you Matthew for the link.

I could get some doc from some articles talking about pragmatic so I guess
I'll figure it out eventually.

However, not all tests for ex19 are working, namely those tests involving
the -do_L2 argument : it appears, when it reaches the first
DMProjectFunction in the testProjectionL2 function (line 201) that it keeps
failing in DMProjectLocal_Generic_Plex with the error :
The section point (0) closure size 0 != dual space dimension 2

where the "dimension 2" changes to "dimension 3" if the case is 3D but
nothing else. Whatever the FEM quadrature it fails at this point.
Now I am just asking out of curiosity because I saw the TODO : broken
mentions so I guess it is not actually supported on the master at this
moment.

Thank you for your help anyways !

Thibault

Le mar. 1 sept. 2020 à 21:24, Matthew Knepley <knepley at gmail.com> a écrit :

> 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/20200902/e56eb5b1/attachment-0001.html>