[petsc-dev] Inquiry about contributing to MMG interface
neil liu
liufield at gmail.com
Sun Feb 9 09:02:43 CST 2025
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? *
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!faRBXMsmlfAC_oR19IbOErwTHRKuoFQVzQ-fThPRV0EgaGlUcfVMnmR7rHPSSW2Q_uE7YMU6DQ0Cz3z2EX5Hcw$ >
>>>>>
>>>>
>>>> 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!faRBXMsmlfAC_oR19IbOErwTHRKuoFQVzQ-fThPRV0EgaGlUcfVMnmR7rHPSSW2Q_uE7YMU6DQ0Cz3zrPXEApQ$
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>> 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!faRBXMsmlfAC_oR19IbOErwTHRKuoFQVzQ-fThPRV0EgaGlUcfVMnmR7rHPSSW2Q_uE7YMU6DQ0Cz3xu-FBVYg$
>>>>>>>>>>> <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!faRBXMsmlfAC_oR19IbOErwTHRKuoFQVzQ-fThPRV0EgaGlUcfVMnmR7rHPSSW2Q_uE7YMU6DQ0Cz3xu-FBVYg$
>>>>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!faRBXMsmlfAC_oR19IbOErwTHRKuoFQVzQ-fThPRV0EgaGlUcfVMnmR7rHPSSW2Q_uE7YMU6DQ0Cz3xprov-7g$ >
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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!faRBXMsmlfAC_oR19IbOErwTHRKuoFQVzQ-fThPRV0EgaGlUcfVMnmR7rHPSSW2Q_uE7YMU6DQ0Cz3xu-FBVYg$
>>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!faRBXMsmlfAC_oR19IbOErwTHRKuoFQVzQ-fThPRV0EgaGlUcfVMnmR7rHPSSW2Q_uE7YMU6DQ0Cz3xprov-7g$ >
>>>>>>
>>>>>
>>>>
>>>> --
>>>> 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!faRBXMsmlfAC_oR19IbOErwTHRKuoFQVzQ-fThPRV0EgaGlUcfVMnmR7rHPSSW2Q_uE7YMU6DQ0Cz3xu-FBVYg$
>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!faRBXMsmlfAC_oR19IbOErwTHRKuoFQVzQ-fThPRV0EgaGlUcfVMnmR7rHPSSW2Q_uE7YMU6DQ0Cz3xprov-7g$ >
>>>>
>>>
>>
>> --
>> 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!faRBXMsmlfAC_oR19IbOErwTHRKuoFQVzQ-fThPRV0EgaGlUcfVMnmR7rHPSSW2Q_uE7YMU6DQ0Cz3xu-FBVYg$
>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!faRBXMsmlfAC_oR19IbOErwTHRKuoFQVzQ-fThPRV0EgaGlUcfVMnmR7rHPSSW2Q_uE7YMU6DQ0Cz3xprov-7g$ >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20250209/3fb8b26c/attachment-0001.html>
More information about the petsc-dev
mailing list