[petsc-dev] Inquiry about contributing to MMG interface
Matthew Knepley
knepley at gmail.com
Sun Feb 9 10:27:56 CST 2025
On Sun, Feb 9, 2025 at 10:02 AM neil liu <liufield at gmail.com> wrote:
> Hi, Matt,
>
> I am working on extending the interface. So far so good. Almost finished
> that for all related functions.
> I have a question about the lines inside DMAdaptMetric_Mmg_Plex(),
>
> * if (rgLabel) {*
> * PetscCall(PetscObjectGetName((PetscObject)rgLabel, &rgLabelName));*
> * PetscCall(PetscStrcmp(rgLabelName, rgName, &flg));*
> * PetscCheck(!flg, comm, PETSC_ERR_ARG_WRONG, "\"%s\" cannot be used as
> label for element tags", rgLabelName);*
> * }*
>
> My confusion,
> *Here, rdgLabelName is "Cell_Sets", rgName is "_regions_". Then flg is
> also petsc_false. *
> *So what is the purpose to add these lines? *
>
This is the name I use internally for Plex regions. The user can choose
another name if they want to control things, but
not overwrite my name.
Thanks,
Matt
> Thanks,
>
> Xiaodong
>
> On Wed, Feb 5, 2025 at 3:12 PM neil liu <liufield at gmail.com> wrote:
>
>> 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!eio8Dp0HNCcecO8TlUYs6sZL7eLayskIzrBPG5C-vVzzmPoZQp-Ms-f-ZAJcveBwSd9q8VMHBB4_7Otz5JGp$ >
>>>>>>
>>>>>
>>>>> 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!eio8Dp0HNCcecO8TlUYs6sZL7eLayskIzrBPG5C-vVzzmPoZQp-Ms-f-ZAJcveBwSd9q8VMHBB4_7HPt06B0$
>>>>>>>>>> .
>>>>>>>>>>
>>>>>>>>>> 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!eio8Dp0HNCcecO8TlUYs6sZL7eLayskIzrBPG5C-vVzzmPoZQp-Ms-f-ZAJcveBwSd9q8VMHBB4_7J1zbu_G$
>>>>>>>>>>>> <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!eio8Dp0HNCcecO8TlUYs6sZL7eLayskIzrBPG5C-vVzzmPoZQp-Ms-f-ZAJcveBwSd9q8VMHBB4_7J1zbu_G$
>>>>>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eio8Dp0HNCcecO8TlUYs6sZL7eLayskIzrBPG5C-vVzzmPoZQp-Ms-f-ZAJcveBwSd9q8VMHBB4_7IRLpirf$ >
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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!eio8Dp0HNCcecO8TlUYs6sZL7eLayskIzrBPG5C-vVzzmPoZQp-Ms-f-ZAJcveBwSd9q8VMHBB4_7J1zbu_G$
>>>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eio8Dp0HNCcecO8TlUYs6sZL7eLayskIzrBPG5C-vVzzmPoZQp-Ms-f-ZAJcveBwSd9q8VMHBB4_7IRLpirf$ >
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> 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!eio8Dp0HNCcecO8TlUYs6sZL7eLayskIzrBPG5C-vVzzmPoZQp-Ms-f-ZAJcveBwSd9q8VMHBB4_7J1zbu_G$
>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eio8Dp0HNCcecO8TlUYs6sZL7eLayskIzrBPG5C-vVzzmPoZQp-Ms-f-ZAJcveBwSd9q8VMHBB4_7IRLpirf$ >
>>>>>
>>>>
>>>
>>> --
>>> 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!eio8Dp0HNCcecO8TlUYs6sZL7eLayskIzrBPG5C-vVzzmPoZQp-Ms-f-ZAJcveBwSd9q8VMHBB4_7J1zbu_G$
>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eio8Dp0HNCcecO8TlUYs6sZL7eLayskIzrBPG5C-vVzzmPoZQp-Ms-f-ZAJcveBwSd9q8VMHBB4_7IRLpirf$ >
>>>
>>
--
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!eio8Dp0HNCcecO8TlUYs6sZL7eLayskIzrBPG5C-vVzzmPoZQp-Ms-f-ZAJcveBwSd9q8VMHBB4_7J1zbu_G$ <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eio8Dp0HNCcecO8TlUYs6sZL7eLayskIzrBPG5C-vVzzmPoZQp-Ms-f-ZAJcveBwSd9q8VMHBB4_7IRLpirf$ >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20250209/bff0924b/attachment-0001.html>
More information about the petsc-dev
mailing list