Hi, Matt,
I just finished testing the 3D cases. Currently, the internal boundary is
enabled through hardcoding in the code. It might be a good idea for you to
review the implementation before I proceed with the 2D case and incorporate
the internal boundary feature into dmplex->metricCtx. Please let me know
what do you prefer.
Test it with Valgrind. There are no memory leaks, but some memory is still
reachable. I checked the details. Some of these still reachable memories
come from DMPlexCreateGmsh.
==1270244== HEAP SUMMARY:
==1270244== in use at exit: 701,196 bytes in 473 blocks
==1270244== total heap usage: 9,775 allocs, 9,263 frees, 10,553,085 bytes
allocated
==1270244==
==1270244== LEAK SUMMARY:
==1270244== definitely lost: 0 bytes in 0 blocks
==1270244== indirectly lost: 0 bytes in 0 blocks
==1270244== possibly lost: 0 bytes in 0 blocks
==1270244== still reachable: 701,196 bytes in 473 blocks
==1270244== suppressed: 0 bytes in 0 blocks
==1270244== Reachable blocks (those to which a pointer was found) are not
shown.
==1270244== To see them, rerun with: --leak-check=full --show-leak-kinds=all
Thansk,
Xiaodong
On Sun, Feb 9, 2025 at 11:28 AM Matthew Knepley <knep...@gmail.com> wrote:
> On Sun, Feb 9, 2025 at 10:02 AM neil liu <liufi...@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 <liufi...@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 <knep...@gmail.com>
>>> wrote:
>>>
>>>> On Wed, Feb 5, 2025 at 2:06 PM neil liu <liufi...@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 <knep...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Wed, Feb 5, 2025 at 1:24 PM neil liu <liufi...@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!dNDagQYzVDsS7RHRolLp1ZxApyE_MY_JpIE5RnvdL56Yr9IeHdzR8cEgbpikfyGUqGC0TwnFRNzoVNUSN0MayA$
>>>>>>> >
>>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Matt
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Xiaodong
>>>>>>>
>>>>>>> On Wed, Feb 5, 2025 at 1:16 PM Matthew Knepley <knep...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Wed, Feb 5, 2025 at 1:06 PM neil liu <liufi...@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 <knep...@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 <pie...@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!dNDagQYzVDsS7RHRolLp1ZxApyE_MY_JpIE5RnvdL56Yr9IeHdzR8cEgbpikfyGUqGC0TwnFRNzoVNV2_-iELQ$
>>>>>>>>>>>
>>>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Pierre
>>>>>>>>>>>
>>>>>>>>>>> On 5 Feb 2025, at 4:39 PM, neil liu <liufi...@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 <liufi...@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 <
>>>>>>>>>>>> knep...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Feb 5, 2025 at 9:52 AM neil liu <liufi...@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!dNDagQYzVDsS7RHRolLp1ZxApyE_MY_JpIE5RnvdL56Yr9IeHdzR8cEgbpikfyGUqGC0TwnFRNzoVNVhT5SvMw$
>>>>>>>>>>>>>
>>>>>>>>>>>>> <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!dNDagQYzVDsS7RHRolLp1ZxApyE_MY_JpIE5RnvdL56Yr9IeHdzR8cEgbpikfyGUqGC0TwnFRNzoVNVhT5SvMw$
>>>>>>>>>>
>>>>>>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!dNDagQYzVDsS7RHRolLp1ZxApyE_MY_JpIE5RnvdL56Yr9IeHdzR8cEgbpikfyGUqGC0TwnFRNzoVNURHIxjqw$
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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!dNDagQYzVDsS7RHRolLp1ZxApyE_MY_JpIE5RnvdL56Yr9IeHdzR8cEgbpikfyGUqGC0TwnFRNzoVNVhT5SvMw$
>>>>>>>>
>>>>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!dNDagQYzVDsS7RHRolLp1ZxApyE_MY_JpIE5RnvdL56Yr9IeHdzR8cEgbpikfyGUqGC0TwnFRNzoVNURHIxjqw$
>>>>>>>> >
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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!dNDagQYzVDsS7RHRolLp1ZxApyE_MY_JpIE5RnvdL56Yr9IeHdzR8cEgbpikfyGUqGC0TwnFRNzoVNVhT5SvMw$
>>>>>>
>>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!dNDagQYzVDsS7RHRolLp1ZxApyE_MY_JpIE5RnvdL56Yr9IeHdzR8cEgbpikfyGUqGC0TwnFRNzoVNURHIxjqw$
>>>>>> >
>>>>>>
>>>>>
>>>>
>>>> --
>>>> 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!dNDagQYzVDsS7RHRolLp1ZxApyE_MY_JpIE5RnvdL56Yr9IeHdzR8cEgbpikfyGUqGC0TwnFRNzoVNVhT5SvMw$
>>>>
>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!dNDagQYzVDsS7RHRolLp1ZxApyE_MY_JpIE5RnvdL56Yr9IeHdzR8cEgbpikfyGUqGC0TwnFRNzoVNURHIxjqw$
>>>> >
>>>>
>>>
>
> --
> 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!dNDagQYzVDsS7RHRolLp1ZxApyE_MY_JpIE5RnvdL56Yr9IeHdzR8cEgbpikfyGUqGC0TwnFRNzoVNVhT5SvMw$
>
> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!dNDagQYzVDsS7RHRolLp1ZxApyE_MY_JpIE5RnvdL56Yr9IeHdzR8cEgbpikfyGUqGC0TwnFRNzoVNURHIxjqw$
> >
>
