[petsc-dev] Inquiry about contributing to MMG interface

neil liu liufield at gmail.com
Wed Feb 5 13:06:40 CST 2025 

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.

On Wed, Feb 5, 2025 at 1:56 PM Matthew Knepley <knepley at gmail.com> wrote:

> On Wed, Feb 5, 2025 at 1:24 PM neil liu <liufield at 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!Ypm4yd4hRprE95itjnveMlx5yLOmJKPzGZS0cgXvMdMNZHT0ZQ1IPxI69dgfBukSVrd98j0FGkIz9smmTncFtw$ >
>>
>
>   Thanks,
>
>      Matt
>
>
>> 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!Ypm4yd4hRprE95itjnveMlx5yLOmJKPzGZS0cgXvMdMNZHT0ZQ1IPxI69dgfBukSVrd98j0FGkIz9skJL5kwxA$ 
>>>>>> .
>>>>>>
>>>>>> 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!Ypm4yd4hRprE95itjnveMlx5yLOmJKPzGZS0cgXvMdMNZHT0ZQ1IPxI69dgfBukSVrd98j0FGkIz9smObQ1JUg$ 
>>>>>>>> <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!Ypm4yd4hRprE95itjnveMlx5yLOmJKPzGZS0cgXvMdMNZHT0ZQ1IPxI69dgfBukSVrd98j0FGkIz9smObQ1JUg$ 
>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!Ypm4yd4hRprE95itjnveMlx5yLOmJKPzGZS0cgXvMdMNZHT0ZQ1IPxI69dgfBukSVrd98j0FGkIz9smDg7r_AA$ >
>>>>>
>>>>
>>>
>>> --
>>> 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!Ypm4yd4hRprE95itjnveMlx5yLOmJKPzGZS0cgXvMdMNZHT0ZQ1IPxI69dgfBukSVrd98j0FGkIz9smObQ1JUg$ 
>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!Ypm4yd4hRprE95itjnveMlx5yLOmJKPzGZS0cgXvMdMNZHT0ZQ1IPxI69dgfBukSVrd98j0FGkIz9smDg7r_AA$ >
>>>
>>
>
> --
> 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!Ypm4yd4hRprE95itjnveMlx5yLOmJKPzGZS0cgXvMdMNZHT0ZQ1IPxI69dgfBukSVrd98j0FGkIz9smObQ1JUg$ 
> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!Ypm4yd4hRprE95itjnveMlx5yLOmJKPzGZS0cgXvMdMNZHT0ZQ1IPxI69dgfBukSVrd98j0FGkIz9smDg7r_AA$ >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20250205/1212b4e8/attachment.html>

More information about the petsc-dev mailing list