[petsc-dev] Inquiry about contributing to MMG interface
Matthew Knepley
knepley at gmail.com
Wed Feb 5 13:43:12 CST 2025
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!a12JvlI5-IXiu6Hwt1OIe5YTPgfodZk6ktB8jtPM3CNaq6bks6hmIQ9m7eYvWH2ckwVHOX_DJWHtE8B3aWuU$ >
>>>
>>
>> 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!a12JvlI5-IXiu6Hwt1OIe5YTPgfodZk6ktB8jtPM3CNaq6bks6hmIQ9m7eYvWH2ckwVHOX_DJWHtE1Woy6zC$
>>>>>>> .
>>>>>>>
>>>>>>> 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!a12JvlI5-IXiu6Hwt1OIe5YTPgfodZk6ktB8jtPM3CNaq6bks6hmIQ9m7eYvWH2ckwVHOX_DJWHtE3cxbuL5$
>>>>>>>>> <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!a12JvlI5-IXiu6Hwt1OIe5YTPgfodZk6ktB8jtPM3CNaq6bks6hmIQ9m7eYvWH2ckwVHOX_DJWHtE3cxbuL5$
>>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!a12JvlI5-IXiu6Hwt1OIe5YTPgfodZk6ktB8jtPM3CNaq6bks6hmIQ9m7eYvWH2ckwVHOX_DJWHtE3-t_-gv$ >
>>>>>>
>>>>>
>>>>
>>>> --
>>>> 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!a12JvlI5-IXiu6Hwt1OIe5YTPgfodZk6ktB8jtPM3CNaq6bks6hmIQ9m7eYvWH2ckwVHOX_DJWHtE3cxbuL5$
>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!a12JvlI5-IXiu6Hwt1OIe5YTPgfodZk6ktB8jtPM3CNaq6bks6hmIQ9m7eYvWH2ckwVHOX_DJWHtE3-t_-gv$ >
>>>>
>>>
>>
>> --
>> 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!a12JvlI5-IXiu6Hwt1OIe5YTPgfodZk6ktB8jtPM3CNaq6bks6hmIQ9m7eYvWH2ckwVHOX_DJWHtE3cxbuL5$
>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!a12JvlI5-IXiu6Hwt1OIe5YTPgfodZk6ktB8jtPM3CNaq6bks6hmIQ9m7eYvWH2ckwVHOX_DJWHtE3-t_-gv$ >
>>
>
--
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!a12JvlI5-IXiu6Hwt1OIe5YTPgfodZk6ktB8jtPM3CNaq6bks6hmIQ9m7eYvWH2ckwVHOX_DJWHtE3cxbuL5$ <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!a12JvlI5-IXiu6Hwt1OIe5YTPgfodZk6ktB8jtPM3CNaq6bks6hmIQ9m7eYvWH2ckwVHOX_DJWHtE3-t_-gv$ >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20250205/97542cc1/attachment-0001.html>
More information about the petsc-dev
mailing list