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 <[email protected]> a écrit : > On Tue, Sep 1, 2020 at 7:15 AM Thibault Bridel-Bertomeu < > [email protected]> 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 < >> [email protected]> a écrit : >> >>> Hi everyone, hi Matt, >>> >>> Le lun. 31 août 2020 à 22:03, Matthew Knepley <[email protected]> a >>> écrit : >>> >>>> On Mon, Aug 31, 2020 at 4:00 PM Thibault Bridel-Bertomeu < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> Le lun. 31 août 2020 à 20:35, Matthew Knepley <[email protected]> a >>>>> écrit : >>>>> >>>>>> On Mon, Aug 31, 2020 at 9:45 AM Thibault Bridel-Bertomeu < >>>>>> [email protected]> 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 <[email protected]> a >>>>>>> écrit : >>>>>>> >>>>>>>> On Mon, Aug 31, 2020 at 5:34 AM Thibault Bridel-Bertomeu < >>>>>>>> [email protected]> 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: [email protected] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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: [email protected] >>>>> >>>> >>>> >>>> -- >>>> 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/> >
