Please take a review ,
If you have any questions, please let me know.
https://urldefense.us/v3/__https://gitlab.com/xiaodongspace/petsc__;!!G_uCfscf7eWS!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRhhGBzyIg$
On Sun, Feb 16, 2025 at 8:40 AM Matthew Knepley <knep...@gmail.com> wrote:
> 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!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRjAmEXNzQ$
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>
>>>>>>>> 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!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRg-t7ueyQ$
>>>>>>>>>>>>>
>>>>>>>>>>>>> .
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRh4Mqb8bg$
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <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!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRh4Mqb8bg$
>>>>>>>>>>>>
>>>>>>>>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRhXK_3eIQ$
>>>>>>>>>>>> >
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRh4Mqb8bg$
>>>>>>>>>>
>>>>>>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRhXK_3eIQ$
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRh4Mqb8bg$
>>>>>>>>
>>>>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRhXK_3eIQ$
>>>>>>>> >
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRh4Mqb8bg$
>>>>>>
>>>>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRhXK_3eIQ$
>>>>>> >
>>>>>>
>>>>>
>>>
>>> --
>>> 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!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRh4Mqb8bg$
>>>
>>> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRhXK_3eIQ$
>>> >
>>>
>>
>
> --
> 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!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRh4Mqb8bg$
>
> <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRhXK_3eIQ$
> >
>
