The corners can be set with MMG's own API function, LIBMMG3D_EXPORT int MMG3D_Set_corner(MMG5_pMesh mesh, MMG5_int k);
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); 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!ek8vsDQ99e1ig8MCItB1OYQeBIVxcpl7zKUmsq1-x-AyFwzcZbLXaz25EaYO3B2kZihoCMNui1qCSXKYxlVwOg$ > 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!ek8vsDQ99e1ig8MCItB1OYQeBIVxcpl7zKUmsq1-x-AyFwzcZbLXaz25EaYO3B2kZihoCMNui1qCSXJQ3rQNtQ$ >>>> >>>> . >>>> >>>> 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!ek8vsDQ99e1ig8MCItB1OYQeBIVxcpl7zKUmsq1-x-AyFwzcZbLXaz25EaYO3B2kZihoCMNui1qCSXL-oCMvHg$ >>>>>> >>>>>> <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!ek8vsDQ99e1ig8MCItB1OYQeBIVxcpl7zKUmsq1-x-AyFwzcZbLXaz25EaYO3B2kZihoCMNui1qCSXL-oCMvHg$ >>> >>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!ek8vsDQ99e1ig8MCItB1OYQeBIVxcpl7zKUmsq1-x-AyFwzcZbLXaz25EaYO3B2kZihoCMNui1qCSXIzp_wlLA$ >>> > >>> >> > > -- > 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!ek8vsDQ99e1ig8MCItB1OYQeBIVxcpl7zKUmsq1-x-AyFwzcZbLXaz25EaYO3B2kZihoCMNui1qCSXL-oCMvHg$ > > <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!ek8vsDQ99e1ig8MCItB1OYQeBIVxcpl7zKUmsq1-x-AyFwzcZbLXaz25EaYO3B2kZihoCMNui1qCSXIzp_wlLA$ > > >
