<div dir="ltr"><span style="color:rgb(85,85,85);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:12px;letter-spacing:0.3px;white-space:nowrap">I think the above Jed's reply declared what I am worried about. That is: if I don't use faking 3D elements,  automatic topological interpolation is not available.   I also notice your discussion with Nicolas.  You suggest users could do it themselves by using GetRawFaces etc.  I think maybe I can try to do it another time.</span><div><span style="color:rgb(85,85,85);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:12px;letter-spacing:0.3px;white-space:nowrap"><br></span></div><div><span style="color:rgb(85,85,85);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:12px;letter-spacing:0.3px;white-space:nowrap">Thank you very much</span></div><div><span style="color:rgb(85,85,85);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:12px;letter-spacing:0.3px;white-space:nowrap"><br></span></div><div><span style="color:rgb(85,85,85);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:12px;letter-spacing:0.3px;white-space:nowrap">Yuan </span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2021年11月3日(水) 20:19 Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>>:<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 Tue, Nov 2, 2021 at 10:49 PM 袁煕 <<a href="mailto:yuanxi@advancesoft.jp" target="_blank">yuanxi@advancesoft.jp</a>> wrote:<br></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">Well! All objects in this world could definitely be modeled as 3D volumes. But considering costs of meshing and following calculations, in most cases it is neither practical nor necessary. And in some specific cases, e.g., to model cell membranes, 2D membrane elements may behave better than 3D volume ones. It is therefore, in many cases, modeling should be much simplified and in some cases they could be modeled as 2D or 1D ones.</div></blockquote><div><br></div><div>I have _never_ suggested using 3D elements, as you can see from my reply to Nicolas. I said you can use _exactly_ the element you want. I am not sure how to be more clear.</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>Following paper is obtained after just google "parachute, FSI"</div><div><div><h1 style="margin-top:0pt;margin-bottom:0pt;margin-left:0pt;text-indent:0pt;padding:0pt;background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial;font-family:SimSun;font-size:24pt"><b><span style="font-family:Arial;color:rgb(17,17,17);letter-spacing:0pt;font-size:9pt;background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial"><a href="https://www.researchgate.net/publication/228719684_A_parallel_3D_computational_method_for_fluid-structure_interactions_in_parachute_systems" target="_blank">A parallel 3D computational method for fluid-structure interactions in parachute systems</a></span></b><b><span style="font-family:Arial;color:rgb(17,17,17);letter-spacing:0pt;font-size:9pt"></span></b></h1></div><div><b><span style="font-family:Arial;color:rgb(17,17,17);letter-spacing:0pt;font-size:9pt;background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial"><br></span></b></div><div><div>You can see they use cable (1D) and membrane (2D) elements to model parachutes. Those public software, such as ABAQUS, ANSYS, NASTRAN, etc all allow the mixed usage of  topologically different elements. They tell the same story. It is the reality and I don't think such reality would change in the near future.</div><div><br></div><div>Best regards</div></div></div><div><br></div><div>Yuan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2021年11月2日(火) 18:22 Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>>:<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 Mon, Nov 1, 2021 at 11:20 PM 袁煕 <<a href="mailto:yuanxi@advancesoft.jp" target="_blank">yuanxi@advancesoft.jp</a>> wrote:<br></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">Dear Matthew,<div><br></div><div>I built a test problem using the strategy you suggested. It works! It is enough for me right now. Thank you very much.</div><div><br><div>!       9----------8----------13 <br>!      /|            /|            /|<br>!     / |           / |           / |<br>!    /  |          /  |          /  |<br>!   6---------7---------12  |<br>!   |   |         |   |         |   |<br>!   |   |         |   |         |   |<br>!   |   |         |   |         |   |<br>!   |   |         |   |         |   |<br>!   |   5------|---4-------|--11--------17------16<br>!   |  /          |  /          |  /            /           /<br>!   | /           | /           | /            /           /<br>!   |/            |/            |/            /           /<br>!   2-- ------3---------10--------14-------15<br><br>      coneSize = (/ 8,8,8,8, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 /)<br>      cones = (/ 2,5,4,3,6,7,8,9,  3,4,11,10,7,12,13,8,  &<br>           10,14,17,11, 10,14,17,11, 14,15,16,17, 14,15,16,17 /)<br></div></div><div><br></div><div>There is still a problem left, however, that is how to build a 3D cell from a 2 vertex segment. I think I could construct a virtual tetrahedron.</div><div><br></div><div>Finally, It can't be denied that this approach needs additional effort in mesh construction (and It is something strange to construct a 3D object from a one dimensional segment). In fact, structures with different topological dimensions are not that rare. Parachute, for example, may be composed with two dimensional parafoil and one dimensional cord. FRP(Fiber reinforced plastics) may be modelled by one dimensional reinforcement and three dimensional plastics. It is therefore, I am wondering, if PETSc would take into consider of such cases by, for example</div><div><br></div><div>-   Enable a face, DM_POLYTOPE_SEGMENT2D, defined by one edge. And</div><div>-   Eable cells, such as DM_POLYTOPE_QUADRILATERAL3D, DM_POLYTOPE_TRIANGLE3D and DM_POLYTOPE_SEGMENT3D, with one face.</div></div></blockquote><div><br></div><div>I think I am still not being completely clear. These types of cells definitely exist. However, let's take the case of the parachute. The one dimensional cords are part of</div><div>the two dimensional patches, which are part of a three dimensional volume. This is how we have modeled it. You assemble different equations on different pieces, but</div><div>that does not affect the mesh.</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>Sorry for a newbie in PETSc to provide such a suggestion. But if it could be accomplished, it would help mech structural engineering, civil engineering, and solid mechanics applicationers.</div><div><br></div><div>Best regards,</div><div><br></div><div>Yuan</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2021年11月1日(月) 18:32 Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>>:<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, Oct 31, 2021 at 12:21 PM 袁煕 <<a href="mailto:yuanxi@advancesoft.jp" target="_blank">yuanxi@advancesoft.jp</a>> wrote:<br></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">Dear Matt<div><br></div><div>Thank you for your detailed explanation. </div><div><br></div><div>First, I would like to answer your question about my application where low dimensional features are not embedded in the larger volume. It is quite general in structural engineering. For example, buildings are generally modelled as shells and beams, which are two and one dimension respectively. While 

<span style="color:rgb(77,81,86);font-family:arial,sans-serif;font-size:14px">building foundation</span> is modelled by solid elements, which is three dimension, at the same time.</div></div></blockquote><div><br></div><div>I think I see what you want now. Let me make a suggestion (along the lines of what Mark said), and attempt to justify it by answering some questions.</div><div><br></div><div>Suggestion: I think you should consider using a volumetric mesh for your problem</div><div><br></div><div>Q1: Can I get the same algebraic system this way?</div><div><br></div><div>Yes. You would only assign unknowns to faces and edges of the mesh where you have shell and beam elements.</div><div><br></div><div>Q2: What are the advantages?</div><div><br></div><div>You would get topological connectivity of all parts of the structure, automatic coupling of the different formulations,</div><div>and you could separately solve the different structures using block preconditioners, while still forming a unified</div><div>residual so that you can guarantee a consistent solution.</div><div><br></div><div>Q3: Wouldn't this be expensive?</div><div><br></div><div>No. For the shells and beams, you would still need the vertices, edges, and faces. First, by the Euler relation, these would</div><div>outnumbers the additional cells. Second, since no unknowns would be associated with the cells, only additional memory in</div><div>the mesh would be used, not the system solves. Memory and time are dominated by the solve, so this should be in the noise.</div><div><br></div><div>  What do you think?</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>Secondly, It is regrettably to find that DMComposite is not available for me, because all my solid, shell, and beam elements are connected each other.</div><div><br></div><div>At last, I have build a simple program to see if DMPlexSetCellType() works for me, following the suggestion of functions in PETSc like DMPlexCreateCGNS. But it failed when it tried to do DMPlexInterpolate</div><div>!       9----------8---------13 <br>!      /|            /|            /|<br>!     / |           / |           / |<br>!    /  |          /  |          /  |<br>!   6---------7---------12  |<br>!   |   |         |   |         |   |<br>!   |   |         |   |         |   |<br>!   |   |         |   |         |   |<br>!   |   |         |   |         |   |<br>!   |   5------|---4-------|-11--------17--------16<br>!   |  /          |  /          |  /            /           /<br>!   | /           | /           | /            /           /<br>!   |/            |/            |/            /           /<br>!   2---------3---------10--------14-------15<br></div><div><br></div><div>The calculation result are follows. It seems that the cell type are set correctly but depth is still 2. </div><div>--------------------------------------------------------------------</div><div>DM Object: TestMesh 2 MPI processes<br>  type: plex<br>TestMesh in 3 dimensions:<br>  0-cells: 16 0<br>  3-cells: 20 (18) 0<br>Labels:<br>  celltype: 3 strata with value/size (7 (2), 4 (2), 0 (16))<br>  depth: 2 strata with value/size (0 (16), 1 (20))<br>[0]PETSC ERROR: --------------------- Error Message --------------------------------------------------------------<br>[0]PETSC ERROR: Object is in wrong state<br>[0]PETSC ERROR: Array was not checked out<br>[0]PETSC ERROR: See <a href="https://petsc.org/release/faq/" target="_blank">https://petsc.org/release/faq/</a> for trouble shooting.<br>[0]PETSC ERROR: Petsc Development GIT revision: v3.16.0-351-g743e004674  GIT Date: 2021-10-29 09:32:23 -0500<br>[0]PETSC ERROR: ./ex3f90 on a arch-linux-c-debug named DESKTOP-9ITFSBM by hillyuan Mon Nov  1 00:26:39 2021<br>[0]PETSC ERROR: Configure options --with-cc=mpiicc --with-cxx=mpiicpc --with-fc=mpiifort --with-fortran-bindings=1 --with-blaslapack-dir=/opt/intel/oneapi/mkl/2021.3.0 --with-mkl_pardiso-dir=/opt/intel/oneapi/mkl/2021.3.0<br>[0]PETSC ERROR: #1 DMRestoreWorkArray() at /home/hillyuan/programs/petsc/src/dm/interface/dm.c:1580<br>[0]PETSC ERROR: #2 DMPlexRestoreRawFaces_Internal() at /home/hillyuan/programs/petsc/src/dm/impls/plex/plexinterpolate.c:323<br>[0]PETSC ERROR: #3 DMPlexInterpolateFaces_Internal() at /home/hillyuan/programs/petsc/src/dm/impls/plex/plexinterpolate.c:375<br>[0]PETSC ERROR: #4 DMPlexInterpolate() at /home/hillyuan/programs/petsc/src/dm/impls/plex/plexinterpolate.c:1340<br></div><div>-----------------------------------------------------------------------------------------</div><div>I attached my test program in this mail. It is much appreciated that you could provide any suggestion.</div><div><br></div><div>Best regards,</div><div><br></div><div>Yuan</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2021年10月31日(日) 21:16 Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>>:<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 Thu, Oct 28, 2021 at 10:48 PM 袁煕 <<a href="mailto:yuanxi@advancesoft.jp" target="_blank">yuanxi@advancesoft.jp</a>> wrote:<br></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"><span style="color:rgb(80,0,80)">Dear Matt,</span><div><font color="#500050"><br></font></div><div><font color="#500050">    My mesh is something like the following figure, which is composed of three elements : one hexahedron(solid element), one quadrilateral (shell element), and one line (beam element). I found the function "</font>TestEmptyStrata" in file \dm\impls\plex\tests\ex11.c would be a good example to read in such a kind of mesh by using DMPlexSetCone. But a problem is that you should declare all faces and edges of <span style="color:rgb(80,0,80)">hexahedron element, all edges in </span><span style="color:rgb(80,0,80)">quadrilateral</span><span style="color:rgb(80,0,80)">  element by </span>DMPlexSetCone<span style="color:rgb(80,0,80)">, otherwise PETsc could not do topological interpolation afterwards. Am I right here?</span></div><div><span style="color:rgb(80,0,80)">   As general in FEM mesh, my mesh does not contain any information about </span>faces or edges of solid elements. That's why I consider using DMCOMPOSITE. That is</div><div><br></div><div>-   Put <span style="color:rgb(80,0,80)">hexahedron, quadrilateral, and line elements into different  DM structures.</span></div><div><span style="color:rgb(80,0,80)">-   </span><span style="color:rgb(80,0,80)">do topological interpolation in those DMs separately.</span></div><div><span style="color:rgb(80,0,80)">-   composite them.</span></div><div><span style="color:rgb(80,0,80)"><br></span></div><div><span style="color:rgb(80,0,80)">   Is there anything wrong in my above consideration?  Any suggestions?</span></div><div><div><br></div><div>        ------------    <br>      /|             /|     <br>     / |           /  |  cell 0: Hex<br>    /  |          /   |  <br>   ------------/   |<br>   |   |         |   |     <br>   |   |         |   |   cell 1: Quad<br>   |   --------|---|------------<br>   |  /          |  /             /<br>   | /           | /             /<br>   |/            |/             /<br>   -------------------------------------------<br>                                  cell 2: line<br></div></div><div><br></div><div>Much thanks for your help.</div></div></blockquote><div><br></div><div>If you are solving something where everything is embedded in a volumetric mesh, then there is no problem. However, if you really have</div><div>the mesh above, where lower dimensional pieces are sticking out of the mesh, then Plex can represent the mesh, but automatic interpolation</div><div>(creation of edges and faces) will not work. Why is this? We use depth in the DAG as a proxy for cell dimension, but this will no longer work</div><div>if faces are not part of a volume.</div><div><br></div><div>Will DMCOMPOSITE do what you want? It depends. It will be able to lay out a vector, but it will not know about any topological connectivity</div><div>between the meshes and will not preallocate a Jacobian with any interaction. If the meshes are truly separate, this is fine. If not, it is not that</div><div>useful.</div><div><br></div><div>Could you modify the existing code to support this? Yes, it would not be terribly difficult. When you load the mesh, you must know what kind</div><div>of cell you are loading. You could explicitly set this using DMPlexSetCellType(). Then, instead of taking a certain height stratum of the DAG</div><div>to loop over, you would instead use all cells marked with a certain cell type. The rest of the interpolation code should work fine.</div><div><br></div><div>What kind of physics do you have where low dimensional features are not embedded in the larger volume?</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>Yuan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2021年10月28日(木) 22:05 Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>>:<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 Thu, Oct 28, 2021 at 4:59 AM 袁煕 <<a href="mailto:yuanxi@advancesoft.jp" target="_blank">yuanxi@advancesoft.jp</a>> wrote:<br></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>Dear Matt,</div><div><br></div>Thank you for your quick response.<br><div><br></div><div><span style="color:rgb(0,0,0)"></span>I think what you mean is to build DAG from my mesh at first and then call <a href="https://petsc.org/main/docs/manualpages/DMPLEX/DMPlexCreateFromDAG.html#DMPlexCreateFromDAG" target="_blank">DMPlexCreateFromDAG</a><span style="color:rgb(0,0,0)">() to construct DMPlex. </span></div></div></blockquote><div><br></div><div>No, I do not mean that.</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><span style="color:rgb(0,0,0)">A new problem is,  as I know,</span><span style="color:rgb(0,0,0)"> the function </span>DMPlexInterpolate would generate points with different depth. What's the difference  between those faces and segment elements generated by  DMPlexInterpolate  with that defined by the original mesh, or should we not use DMPlexInterpolate in such a case?</div><div><br></div><div>On the other hand, can DMComposite be used in this case by defining DMPlex with different topological dimensions at first and then composite them?</div></div></blockquote><div><br></div><div>You do not need that. I am obviously not understanding your question. My short answer is that Plex _already_ handles cells of different</div><div>dimension automatically without anything extra.</div><div><br></div><div>Maybe it would help if you defined a specific problem you have.</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>Thanks in advance.</div><div><br></div><div>Yuan</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2021年10月27日(水) 19:27 Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>>:<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, Oct 27, 2021 at 4:50 AM 袁煕 <<a href="mailto:yuanxi@advancesoft.jp" target="_blank">yuanxi@advancesoft.jp</a>> wrote:<br></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,<br><div><br></div><div>I am trying to parallelize my serial FEM program using PETSc. This program calculates structure deformation by using various types of elements such as solid, shell, beam, and truss. At the very beginning, I found it was hard for me to put such kinds of elements into DMPlex. Because solid elements are topologically three dimensional, shell element two, and beam or truss are topologically one-dimensional elements. After reading chapter 2.10: "DMPlex: Unstructured Grids in PETSc" of users manual carefully,  I found the provided functions, such as DMPlexSetCone, cannot declare those topological differences.</div><div><br></div><div>My question is : Is it possible and how to define all those topologically different elements into a DMPlex struct?</div></div></blockquote><div><br></div><div>Yes. The idea is to program in a dimension-independent way, so that the code can handle cells of any dimension.</div><div>What you probably want is the "depth" in the DAG representation, which you can think of as the dimension of a cell.</div><div><br></div><div>  <a href="https://petsc.org/main/docs/manualpages/DMPLEX/DMPlexGetPointDepth.html#DMPlexGetPointDepth" target="_blank">https://petsc.org/main/docs/manualpages/DMPLEX/DMPlexGetPointDepth.html#DMPlexGetPointDepth</a></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>Thanks in advance!</div><div><br></div><div>Best regards,</div><div><br></div><div>Yuan.</div><div><br></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><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="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><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="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><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="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><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="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><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="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><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="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div>