[petsc-dev] Inquiry about contributing to MMG interface
Matthew Knepley
knepley at gmail.com
Wed Feb 5 12:55:51 CST 2025
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!bKdWOtCvA_Azjc29v2WxofGzpDjbNC-541kCXKvj0mo0SQ3dcS8irHwWYb3ckQSWb9JR7g5WkUqnonymjfwv$ >
>
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!bKdWOtCvA_Azjc29v2WxofGzpDjbNC-541kCXKvj0mo0SQ3dcS8irHwWYb3ckQSWb9JR7g5WkUqnorKeyTJt$
>>>>> .
>>>>>
>>>>> 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!bKdWOtCvA_Azjc29v2WxofGzpDjbNC-541kCXKvj0mo0SQ3dcS8irHwWYb3ckQSWb9JR7g5WkUqnojvlDqER$
>>>>>>> <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!bKdWOtCvA_Azjc29v2WxofGzpDjbNC-541kCXKvj0mo0SQ3dcS8irHwWYb3ckQSWb9JR7g5WkUqnojvlDqER$
>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!bKdWOtCvA_Azjc29v2WxofGzpDjbNC-541kCXKvj0mo0SQ3dcS8irHwWYb3ckQSWb9JR7g5WkUqnorzjJhf8$ >
>>>>
>>>
>>
>> --
>> 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!bKdWOtCvA_Azjc29v2WxofGzpDjbNC-541kCXKvj0mo0SQ3dcS8irHwWYb3ckQSWb9JR7g5WkUqnojvlDqER$
>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!bKdWOtCvA_Azjc29v2WxofGzpDjbNC-541kCXKvj0mo0SQ3dcS8irHwWYb3ckQSWb9JR7g5WkUqnorzjJhf8$ >
>>
>
--
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!bKdWOtCvA_Azjc29v2WxofGzpDjbNC-541kCXKvj0mo0SQ3dcS8irHwWYb3ckQSWb9JR7g5WkUqnojvlDqER$ <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!bKdWOtCvA_Azjc29v2WxofGzpDjbNC-541kCXKvj0mo0SQ3dcS8irHwWYb3ckQSWb9JR7g5WkUqnorzjJhf8$ >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20250205/ec18f3c3/attachment-0001.html>
More information about the petsc-dev
mailing list