On Sat, Feb 15, 2025 at 11:05 PM neil liu <liufi...@gmail.com> wrote:
> 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.
>
Hi Xiaodong,
I have misplaced the branch ref. Can you mail me the URL and I will review?
> 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
>
Yes, that is GMsh memory. We tag all our allocs and check at the end, so it
is not malloced by PETSc.
Thanks!
Matt
> 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!dK74svNUpnPLsHWvvZevisu5cbOUEgu3J2A3xrmfPayCgs9XZUqlmvVu4Ar4CtNXOuib0khV9T0STIa4XbJp$
>>>>>>>> >
>>>>>>>>
>>>>>>>
>>>>>>> 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!dK74svNUpnPLsHWvvZevisu5cbOUEgu3J2A3xrmfPayCgs9XZUqlmvVu4Ar4CtNXOuib0khV9T0STM5co4WK$
>>>>>>>>>>>>
>>>>>>>>>>>> .
>>>>>>>>>>>>
>>>>>>>>>>>> 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!dK74svNUpnPLsHWvvZevisu5cbOUEgu3J2A3xrmfPayCgs9XZUqlmvVu4Ar4CtNXOuib0khV9T0STJXA64i4$
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <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!dK74svNUpnPLsHWvvZevisu5cbOUEgu3J2A3xrmfPayCgs9XZUqlmvVu4Ar4CtNXOuib0khV9T0STJXA64i4$
>>>>>>>>>>>
>>>>>>>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!dK74svNUpnPLsHWvvZevisu5cbOUEgu3J2A3xrmfPayCgs9XZUqlmvVu4Ar4CtNXOuib0khV9T0STA2mb878$
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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!dK74svNUpnPLsHWvvZevisu5cbOUEgu3J2A3xrmfPayCgs9XZUqlmvVu4Ar4CtNXOuib0khV9T0STJXA64i4$
>>>>>>>>>
>>>>>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!dK74svNUpnPLsHWvvZevisu5cbOUEgu3J2A3xrmfPayCgs9XZUqlmvVu4Ar4CtNXOuib0khV9T0STA2mb878$
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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!dK74svNUpnPLsHWvvZevisu5cbOUEgu3J2A3xrmfPayCgs9XZUqlmvVu4Ar4CtNXOuib0khV9T0STJXA64i4$
>>>>>>>
>>>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!dK74svNUpnPLsHWvvZevisu5cbOUEgu3J2A3xrmfPayCgs9XZUqlmvVu4Ar4CtNXOuib0khV9T0STA2mb878$
>>>>>>> >
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> 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!dK74svNUpnPLsHWvvZevisu5cbOUEgu3J2A3xrmfPayCgs9XZUqlmvVu4Ar4CtNXOuib0khV9T0STJXA64i4$
>>>>>
>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!dK74svNUpnPLsHWvvZevisu5cbOUEgu3J2A3xrmfPayCgs9XZUqlmvVu4Ar4CtNXOuib0khV9T0STA2mb878$
>>>>> >
>>>>>
>>>>
>>
>> --
>> 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!dK74svNUpnPLsHWvvZevisu5cbOUEgu3J2A3xrmfPayCgs9XZUqlmvVu4Ar4CtNXOuib0khV9T0STJXA64i4$
>>
>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!dK74svNUpnPLsHWvvZevisu5cbOUEgu3J2A3xrmfPayCgs9XZUqlmvVu4Ar4CtNXOuib0khV9T0STA2mb878$
>> >
>>
>
--
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!dK74svNUpnPLsHWvvZevisu5cbOUEgu3J2A3xrmfPayCgs9XZUqlmvVu4Ar4CtNXOuib0khV9T0STJXA64i4$
<https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!dK74svNUpnPLsHWvvZevisu5cbOUEgu3J2A3xrmfPayCgs9XZUqlmvVu4Ar4CtNXOuib0khV9T0STA2mb878$
>
