[petsc-dev] Inquiry about contributing to MMG interface

Wed Feb 5 12:24:14 CST 2025

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 <knepley at gmail.com> wrote:

> On Wed, Feb 5, 2025 at 1:06 PM neil liu <liufield at 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 <knepley at 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 <pierre at 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 <liufield at 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 <liufield at 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 <knepley at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Wed, Feb 5, 2025 at 9:52 AM neil liu <liufield at 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$ >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20250205/518d5bdb/attachment.html>