Theoretically, the edges of the open boundary surface can be extracted outside this subroutine. (I am wondering if this can be effectively delivered outside this subroutine.)_
It might be more convenient to assign edge labels and set these edges in MMG using MMG3D_Set_edges. This way, after refinement, the labeled edges can be easily identified. I would appreciate your insights on this. Thanks, Xiaodong On Wed, Feb 5, 2025 at 2:43 PM Matthew Knepley <knep...@gmail.com> wrote: > On Wed, Feb 5, 2025 at 2:06 PM neil liu <liufi...@gmail.com> wrote: > >> For open boundaries, MMG sets a reference for the internal open boundary >> surface and then runs in opnbdy mode after we define the corners using >> MMG3D_Set_corner. >> >> The edges are only desired for my own case. We need to know the edges >> delimiting the open boundary surface after refinement to extract some >> physical data. >> > > Okay, so it seems that we need to extend the interface to MMG to allow > corners to be labeled. You can label edges on your own without extending > the interface I think. Let me know if this is wrong. > > Thanks, > > Matt > > >> On Wed, Feb 5, 2025 at 1:56 PM Matthew Knepley <knep...@gmail.com> wrote: >> >>> On Wed, Feb 5, 2025 at 1:24 PM neil liu <liufi...@gmail.com> wrote: >>> >>>> The corners can be set with MMG's own API function, LIBMMG3D_EXPORT >>>> int MMG3D_Set_corner(MMG5_pMesh mesh, MMG5_int k); >>>> >>> >>> This definitely sets a corner attribute on a vertex. >>> >>> >>>> The edges can be set with MMG's own API function, LIBMMG3D_EXPORT int >>>> MMG3D_Set_edges(MMG5_pMesh mesh, MMG5_int *edges, MMG5_int* refs); >>>> >>> >>> This seems to define all the edges in the mesh. Are you saying that MMG >>> only uses these edge definitions for open boundaries? >>> >>> >>>> MMG doesn't have a very detailed documentation. The above API >>>> subroutines can be found, >>>> mmg/src/mmg3d/libmmg3d.h at master · MmgTools/mmg · GitHub >>>> <https://urldefense.us/v3/__https://github.com/MmgTools/mmg/blob/master/src/mmg3d/libmmg3d.h__;!!G_uCfscf7eWS!eHchA29ilLtNcXaJPQsRYSaMxZfsJX-rgPDUNEbs3OADEmp3w1FYYXRr-kwP1XBYIovf06_ey805m4DPv4c4-A$ >>>> > >>>> >>> >>> Thanks, >>> >>> Matt >>> >>> >>>> Thanks, >>>> >>>> Xiaodong >>>> >>>> On Wed, Feb 5, 2025 at 1:16 PM Matthew Knepley <knep...@gmail.com> >>>> wrote: >>>> >>>>> On Wed, Feb 5, 2025 at 1:06 PM neil liu <liufi...@gmail.com> wrote: >>>>> >>>>>> Hi, Matt, >>>>>> >>>>>> It is not enough to only turn on -the open boundary. >>>>>> For the above example, the 4 physical corner vertices (0D) for this >>>>>> internal quadrilateral surface have to be set, otherwise the shape can >>>>>> not >>>>>> be kept. >>>>>> In addition, for my present case, the boundary edges (1D) consisting >>>>>> of this quadrilateral surface need to be tagged. >>>>>> The present bdLabel seems to only work for 2D shapes for 3D cases. >>>>>> Please correct me if I am wrong. >>>>>> >>>>> >>>>> Are you saying that this is the interface published by MMG? Can you >>>>> point me toward the piece of MMG documentation? I just want to understand >>>>> the interface requirements before we make any changes to PETSc. >>>>> >>>>> Thanks, >>>>> >>>>> Matt >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Xiaodong >>>>>> >>>>>> On Wed, Feb 5, 2025 at 12:05 PM Matthew Knepley <knep...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> This is a really poor name. The boundary is not open in any sense. >>>>>>> It should be called an internal boundary, and what they call internal >>>>>>> boundaries should be called interdomain boundaries, but it seems too >>>>>>> late >>>>>>> to fix this. >>>>>>> >>>>>>> Turning on open boundaries is just a flag, so that is easy, and one >>>>>>> can see the usefulness of this mode. >>>>>>> >>>>>>> My understanding from the documentation link below is that MMG does >>>>>>> not change anything about parts of the mesh marked >>>>>>> as internal boundaries, so we can read them right back out from the >>>>>>> boundary label. Why would we need a new label for this? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> On Wed, Feb 5, 2025 at 11:22 AM Pierre Jolivet <pie...@joliv.et> >>>>>>> wrote: >>>>>>> >>>>>>>> See also: >>>>>>>> https://urldefense.us/v3/__https://www.mmgtools.org/mmg-remesher-try-mmg/mmg-remesher-tutorials/mmg-remesher-mmg3d/open-boundary-remeshing__;!!G_uCfscf7eWS!eHchA29ilLtNcXaJPQsRYSaMxZfsJX-rgPDUNEbs3OADEmp3w1FYYXRr-kwP1XBYIovf06_ey805m4BfhNvWgA$ >>>>>>>> >>>>>>>> . >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Pierre >>>>>>>> >>>>>>>> On 5 Feb 2025, at 4:39 PM, neil liu <liufi...@gmail.com> wrote: >>>>>>>> >>>>>>>> It seems the figures were broken. Please see the following >>>>>>>> attached. >>>>>>>> >>>>>>>> On Wed, Feb 5, 2025 at 10:36 AM neil liu <liufi...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi, Mark, >>>>>>>>> >>>>>>>>> For example, in the left figure, the yellow rectangular face needs >>>>>>>>> to be preserved during mesh refinement. However, without specifying >>>>>>>>> its >>>>>>>>> four corner points, the rectangle cannot be maintained, as shown in >>>>>>>>> the >>>>>>>>> right figure. Additionally, the four edges of this face must be >>>>>>>>> recorded >>>>>>>>> and retrieved for post-processing. >>>>>>>>> >>>>>>>>> This yellow face is an *open boundary*, meaning it is not an >>>>>>>>> interface between different materials. To ensure its preservation >>>>>>>>> during >>>>>>>>> mesh refinement, MMG must be run in *opnbdy* (open boundary) mode. >>>>>>>>> >>>>>>>>> Thanks a lot, >>>>>>>>> >>>>>>>>> Xiaodong >>>>>>>>> [image: image.png] [image: image.png] >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Feb 5, 2025 at 10:05 AM Matthew Knepley <knep...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Wed, Feb 5, 2025 at 9:52 AM neil liu <liufi...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Dear developers, >>>>>>>>>>> >>>>>>>>>>> I am currently working with MMG in the context of PETSc and have >>>>>>>>>>> identified a need to modify the existing MMG interface, >>>>>>>>>>> DMAdaptMetric_Mmg_Plex(), for our use case. Given these >>>>>>>>>>> requirements, I would like to explore the feasibility of >>>>>>>>>>> contributing to >>>>>>>>>>> PETSc to enhance this interface, which has been verified and >>>>>>>>>>> validated in >>>>>>>>>>> our research code. >>>>>>>>>>> *Proposed Modifications:* >>>>>>>>>>> >>>>>>>>>>> 1. >>>>>>>>>>> >>>>>>>>>>> *Additional Labels for Physical Entities:* >>>>>>>>>>> - In addition to the existing bdLabel and rgLabel, our case >>>>>>>>>>> requires two additional labels to represent physical vertices >>>>>>>>>>> and edges >>>>>>>>>>> within the computational domain (3D). >>>>>>>>>>> >>>>>>>>>>> I am open to this. Can you be more specific about what it means? >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 1. >>>>>>>>>>> - One approach is to introduce two new parameters in the >>>>>>>>>>> subroutine’s input list. However, this may require >>>>>>>>>>> modifications across >>>>>>>>>>> related components, such as Pragmatic. >>>>>>>>>>> >>>>>>>>>>> This is not a problem. I can modify those. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 1. >>>>>>>>>>> >>>>>>>>>>> *Support for Open Boundaries:* >>>>>>>>>>> - The current interface does not support open boundaries, a >>>>>>>>>>> feature available in MMG. >>>>>>>>>>> - As a result, several MMG benchmark cases involving open >>>>>>>>>>> boundary remeshing cannot be executed within PETSc. >>>>>>>>>>> >>>>>>>>>>> Can you explain what this means? What is an open boundary >>>>>>>>>> exactly? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Would this be a viable contribution to PETSc? If so, I would >>>>>>>>>>> appreciate any guidance on the best approach to implementing these >>>>>>>>>>> changes >>>>>>>>>>> while maintaining compatibility with existing features. >>>>>>>>>>> >>>>>>>>>> Yes. Please make a fork of the petsc repo, make a branch with the >>>>>>>>>> proposed changes, make an MR for that branch, and add me to your >>>>>>>>>> fork (I am >>>>>>>>>> knepley on GitLab). I can help you get it going. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Matt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Looking forward to your thoughts. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Xiaodong >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eHchA29ilLtNcXaJPQsRYSaMxZfsJX-rgPDUNEbs3OADEmp3w1FYYXRr-kwP1XBYIovf06_ey805m4AwFugkmw$ >>>>>>>>>> >>>>>>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!anvbtQDqn57whvgg2qc1Dix0Izm9kxNlvUkeyYkcfknnt6VmqbCE0mlGSj6O1DLJx6qR7-7UsHv48zbaqVDECw$> >>>>>>>>>> >>>>>>>>> <The right figure.png><The left figure.png> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eHchA29ilLtNcXaJPQsRYSaMxZfsJX-rgPDUNEbs3OADEmp3w1FYYXRr-kwP1XBYIovf06_ey805m4AwFugkmw$ >>>>>>> >>>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eHchA29ilLtNcXaJPQsRYSaMxZfsJX-rgPDUNEbs3OADEmp3w1FYYXRr-kwP1XBYIovf06_ey805m4ANKuwGLg$ >>>>>>> > >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eHchA29ilLtNcXaJPQsRYSaMxZfsJX-rgPDUNEbs3OADEmp3w1FYYXRr-kwP1XBYIovf06_ey805m4AwFugkmw$ >>>>> >>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eHchA29ilLtNcXaJPQsRYSaMxZfsJX-rgPDUNEbs3OADEmp3w1FYYXRr-kwP1XBYIovf06_ey805m4ANKuwGLg$ >>>>> > >>>>> >>>> >>> >>> -- >>> 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eHchA29ilLtNcXaJPQsRYSaMxZfsJX-rgPDUNEbs3OADEmp3w1FYYXRr-kwP1XBYIovf06_ey805m4AwFugkmw$ >>> >>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eHchA29ilLtNcXaJPQsRYSaMxZfsJX-rgPDUNEbs3OADEmp3w1FYYXRr-kwP1XBYIovf06_ey805m4ANKuwGLg$ >>> > >>> >> > > -- > 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://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eHchA29ilLtNcXaJPQsRYSaMxZfsJX-rgPDUNEbs3OADEmp3w1FYYXRr-kwP1XBYIovf06_ey805m4AwFugkmw$ > > <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eHchA29ilLtNcXaJPQsRYSaMxZfsJX-rgPDUNEbs3OADEmp3w1FYYXRr-kwP1XBYIovf06_ey805m4ANKuwGLg$ > > >
