<div dir="ltr"><div dir="ltr">Please take a review , </div><div dir="ltr">If you have any questions, please let me know.</div><div dir="ltr"><br><div><a href="https://urldefense.us/v3/__https://gitlab.com/xiaodongspace/petsc__;!!G_uCfscf7eWS!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRhhGBzyIg$" target="_blank">https://gitlab.com/xiaodongspace/petsc</a></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 16, 2025 at 8:40 AM Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Sat, Feb 15, 2025 at 11:05 PM neil liu <<a href="mailto:liufield@gmail.com" target="_blank">liufield@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi, Matt, <div><br></div><div>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 <code>dmplex->metricCtx</code>. Please let me know what do you prefer. </div></div></div></div></div></div></blockquote><div><br></div><div>Hi Xiaodong,</div><div><br></div><div>I have misplaced the branch ref. Can you mail me the URL and I will review?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>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. </div><div><div><div><div><span><button type="button" id="m_-3689591000012980022m_-4641951409285779407m_2700597490891152184gmail-radix-:rrt:" aria-haspopup="menu" aria-expanded="false"><div><span></span></div></button></span></div></div></div></div><div>==1270244== HEAP SUMMARY:</div><div><div>==1270244== in use at exit: 701,196 bytes in 473 blocks</div><div>==1270244== total heap usage: 9,775 allocs, 9,263 frees, 10,553,085 bytes allocated</div><div>==1270244== </div><div>==1270244== LEAK SUMMARY:</div><div>==1270244== definitely lost: 0 bytes in 0 blocks</div><div>==1270244== indirectly lost: 0 bytes in 0 blocks</div><div>==1270244== possibly lost: 0 bytes in 0 blocks</div><div>==1270244== still reachable: 701,196 bytes in 473 blocks</div><div>==1270244== suppressed: 0 bytes in 0 blocks</div><div>==1270244== Reachable blocks (those to which a pointer was found) are not shown.</div><div>==1270244== To see them, rerun with: --leak-check=full --show-leak-kinds=all</div></div></div></div></div></div></div></blockquote><div><br></div><div>Yes, that is GMsh memory. We tag all our allocs and check at the end, so it is not malloced by PETSc.</div><div><br></div><div> Thanks!</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Thansk,</div><div>Xiaodong </div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 9, 2025 at 11:28 AM Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Sun, Feb 9, 2025 at 10:02 AM neil liu <<a href="mailto:liufield@gmail.com" target="_blank">liufield@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi, Matt, <div><br></div><div>I am working on extending the interface. So far so good. Almost finished that for all related functions. </div><div>I have a question about the lines inside DMAdaptMetric_Mmg_Plex(),</div><div><br></div><div><div><b> if (rgLabel) {</b></div><div><b> PetscCall(PetscObjectGetName((PetscObject)rgLabel, &rgLabelName));</b></div><div><b> PetscCall(PetscStrcmp(rgLabelName, rgName, &flg));</b></div><div><b> PetscCheck(!flg, comm, PETSC_ERR_ARG_WRONG, "\"%s\" cannot be used as label for element tags", rgLabelName);</b></div><div><b> }</b></div></div><div><b><br></b></div><div>My confusion, </div><div><b>Here, rdgLabelName is "Cell_Sets", rgName is "_regions_". Then flg is also petsc_false. </b></div><div><b>So what is the purpose to add these lines? </b></div></div></div></blockquote><div><br></div><div>This is the name I use internally for Plex regions. The user can choose another name if they want to control things, but</div><div>not overwrite my name.</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Thanks, </div><div><br></div><div>Xiaodong </div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 5, 2025 at 3:12 PM neil liu <<a href="mailto:liufield@gmail.com" target="_blank">liufield@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p>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.)_</p><p> It might be more convenient to assign edge labels and set these edges in MMG using <code>MMG3D_Set_edges</code>. This way, after refinement, the labeled edges can be easily identified.</p><p> I would appreciate your insights on this.</p><div><br></div><div>Thanks,</div><div><br></div><div>Xiaodong <br><div><br></div><div><br><br></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 5, 2025 at 2:43 PM Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Wed, Feb 5, 2025 at 2:06 PM neil liu <<a href="mailto:liufield@gmail.com" target="_blank">liufield@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">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. </div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 5, 2025 at 1:56 PM Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Wed, Feb 5, 2025 at 1:24 PM neil liu <<a href="mailto:liufield@gmail.com" target="_blank">liufield@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">The corners can be set with MMG's own API function, LIBMMG3D_EXPORT int MMG3D_Set_corner(MMG5_pMesh mesh, MMG5_int k);</div></div></div></div></div></div></blockquote><div><br></div><div>This definitely sets a corner attribute on a vertex.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>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);</div></div></div></div></div></div></blockquote><div><br></div><div>This seems to define all the edges in the mesh. Are you saying that MMG only uses these edge definitions for open boundaries?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>MMG doesn't have a very detailed documentation. The above API subroutines can be found, </div><div><a href="https://urldefense.us/v3/__https://github.com/MmgTools/mmg/blob/master/src/mmg3d/libmmg3d.h__;!!G_uCfscf7eWS!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRjAmEXNzQ$" target="_blank">mmg/src/mmg3d/libmmg3d.h at master · MmgTools/mmg · GitHub</a></div></div></div></div></div></div></blockquote><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Thanks,</div><div><br></div><div>Xiaodong</div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 5, 2025 at 1:16 PM Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Wed, Feb 5, 2025 at 1:06 PM neil liu <<a href="mailto:liufield@gmail.com" target="_blank">liufield@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi, Matt,<div><br></div><div>It is not enough to only turn on -the open boundary. </div><div>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. </div><div>In addition, for my present case, the boundary edges (1D) consisting of this quadrilateral surface need to be tagged. </div><div>The present bdLabel seems to only work for 2D shapes for 3D cases.</div><div>Please correct me if I am wrong. </div></div></blockquote><div><br></div><div>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.</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks, </div><div><br></div><div>Xiaodong </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 5, 2025 at 12:05 PM Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>Turning on open boundaries is just a flag, so that is easy, and one can see the usefulness of this mode.</div><div><br></div><div>My understanding from the documentation link below is that MMG does not change anything about parts of the mesh marked</div><div>as internal boundaries, so we can read them right back out from the boundary label. Why would we need a new label for this?</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 5, 2025 at 11:22 AM Pierre Jolivet <<a href="mailto:pierre@joliv.et" target="_blank">pierre@joliv.et</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>See also: <a href="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$" target="_blank">https://www.mmgtools.org/mmg-remesher-try-mmg/mmg-remesher-tutorials/mmg-remesher-mmg3d/open-boundary-remeshing</a>.<div><br></div><div>Thanks,</div><div>Pierre<br id="m_-3689591000012980022m_-4641951409285779407m_2700597490891152184m_-5556518980665212066m_7405623267858288786m_2393577460200582001m_695759020280869279m_6934288429362484725m_-3748885229909705110m_834137896634904166m_7177489474945856139m_-5508104525105872091m_374923789566632631m_-7847456199305676236m_3773341779745083509lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On 5 Feb 2025, at 4:39 PM, neil liu <<a href="mailto:liufield@gmail.com" target="_blank">liufield@gmail.com</a>> wrote:</div><br><div><div dir="ltr">It seems the figures were broken. Please see the following attached. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 5, 2025 at 10:36 AM neil liu <<a href="mailto:liufield@gmail.com" target="_blank">liufield@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi, Mark, <div><div><p>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.</p><p>This yellow face is an <strong>open boundary</strong>, meaning it is not an interface between different materials. To ensure its preservation during mesh refinement, MMG must be run in <strong>opnbdy</strong> (open boundary) mode.</p></div><div><br></div><div>Thanks a lot,</div><div><br></div><div>Xiaodong </div><img alt="image.png" width="381" height="321" style="margin-right: 0px;"> <img alt="image.png" width="498" height="321" style="margin-right: 0px;"></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 5, 2025 at 10:05 AM Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Wed, Feb 5, 2025 at 9:52 AM neil liu <<a href="mailto:liufield@gmail.com" target="_blank">liufield@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><font size="4">Dear developers, </font></div><div dir="ltr"><p><font face="tahoma, sans-serif">I am currently working with MMG in the context of PETSc and have identified a need to modify the existing MMG interface, <code>DMAdaptMetric_Mmg_Plex()</code>, 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. </font></p><h3><strong><font face="tahoma, sans-serif">Proposed Modifications:</font></strong></h3><ol><li><p><strong><font face="tahoma, sans-serif">Additional Labels for Physical Entities:</font></strong></p><ul><li><font face="tahoma, sans-serif">In addition to the existing <code>bdLabel</code> and <code>rgLabel</code>, our case requires two additional labels to represent physical vertices and edges within the computational domain (3D).</font></li></ul></li></ol></div></div></div></div></div></div></div></blockquote><div>I am open to this. Can you be more specific about what it means? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><ol><li><ul><li><font face="tahoma, sans-serif">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. </font></li></ul></li></ol></div></div></div></div></div></div></div></blockquote><div>This is not a problem. I can modify those. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><ol><li><p><strong><font face="tahoma, sans-serif">Support for Open Boundaries:</font></strong></p><ul><li><font face="tahoma, sans-serif">The current interface does not support open boundaries, a feature available in MMG.</font></li><li><font face="tahoma, sans-serif">As a result, several MMG benchmark cases involving open boundary remeshing cannot be executed within PETSc.</font></li></ul></li></ol></div></div></div></div></div></div></div></blockquote><div>Can you explain what this means? What is an open boundary exactly?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p><font face="tahoma, sans-serif">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.</font></p></div></div></div></div></div></div></div></blockquote><div>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.</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p><font face="tahoma, sans-serif">Looking forward to your thoughts.</font></p><p><font face="tahoma, sans-serif">Best regards,</font></p></div><div dir="ltr"><span style="font-size:large"><br></span></div><div dir="ltr"><span style="font-size:large">Thanks, </span></div><div dir="ltr"><font size="4">Xiaodong </font><br><div><code><font face="arial black, sans-serif"><b></b></font></code></div><div><code><font face="arial black, sans-serif"><b><br></b></font></code></div><div><code><font face="arial black, sans-serif"><b><br></b></font></code></div><div><code><font face="arial black, sans-serif"><br></font></code></div><div><code><font face="arial black, sans-serif"><br></font></code></div><div><br></div><div><code><font face="arial black, sans-serif"><br></font></code></div><div><code><font face="arial black, sans-serif"><br></font></code></div><div><br></div></div></div></div></div></div></div></div>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!anvbtQDqn57whvgg2qc1Dix0Izm9kxNlvUkeyYkcfknnt6VmqbCE0mlGSj6O1DLJx6qR7-7UsHv48zbaqVDECw$" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div>
<span id="m_-3689591000012980022m_-4641951409285779407m_2700597490891152184m_-5556518980665212066m_7405623267858288786m_2393577460200582001m_695759020280869279m_6934288429362484725m_-3748885229909705110m_834137896634904166m_7177489474945856139m_-5508104525105872091m_374923789566632631m_-7847456199305676236m_3773341779745083509cid:f_m6s2q0541"><The right figure.png></span><span id="m_-3689591000012980022m_-4641951409285779407m_2700597490891152184m_-5556518980665212066m_7405623267858288786m_2393577460200582001m_695759020280869279m_6934288429362484725m_-3748885229909705110m_834137896634904166m_7177489474945856139m_-5508104525105872091m_374923789566632631m_-7847456199305676236m_3773341779745083509cid:f_m6s2q04n0"><The left figure.png></span></div></blockquote></div><br></div></div></blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRhXK_3eIQ$" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRhXK_3eIQ$" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRhXK_3eIQ$" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRhXK_3eIQ$" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRhXK_3eIQ$" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!ax17nsgt3n5EQgX8v3FEpsoJRo0GP05wvQeo8O5mNSNHP3bPlFowbFxDCYGTBy-B8nHhaYJfgHF4WRhXK_3eIQ$" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div>