[petsc-dev] Inquiry about contributing to MMG interface
neil liu
liufield at gmail.com
Wed Feb 5 14:12:28 CST 2025
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 <knepley at gmail.com> wrote:
> On Wed, Feb 5, 2025 at 2:06 PM neil liu <liufield at 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 <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!eHchA29ilLtNcXaJPQsRYSaMxZfsJX-rgPDUNEbs3OADEmp3w1FYYXRr-kwP1XBYIovf06_ey805m4DPv4c4-A$ >
>>>>
>>>
>>> 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!eHchA29ilLtNcXaJPQsRYSaMxZfsJX-rgPDUNEbs3OADEmp3w1FYYXRr-kwP1XBYIovf06_ey805m4BfhNvWgA$
>>>>>>>> .
>>>>>>>>
>>>>>>>> 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!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$ >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20250205/82a47d89/attachment-0001.html>
More information about the petsc-dev
mailing list