[petsc-dev] Inquiry about contributing to MMG interface

[neil liu]

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!daLeqYFwNd0QJ47ANuBplQ_Viu-I_lV-BiTAp6rNk5353-EQGMlxIFhPoffcvwgSqaMQ0ueG8gg2I2npQRB85A$ 
> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!daLeqYFwNd0QJ47ANuBplQ_Viu-I_lV-BiTAp6rNk5353-EQGMlxIFhPoffcvwgSqaMQ0ueG8gg2I2kohNMh3A$ >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20250205/4ca07d05/attachment.html>