DMPlex and Boundary facets
Dear PETSc team, I have tried to load a test mesh available in Gmsh' s demos directory (share/doc/gmsh/demos/simple_geo/filter.geo, attached to this email) as a DMPlex. So I produced a msh4 file by doing : gmsh -3 filter.geo -o /tmp/test.msh4 Then I used src/dm/impls/plex/tutorials/ex2.c to load the mesh by doing : ./ex2 -filename /tmp/test.msh4 Unfortunately I get the error : [0]PETSC ERROR: --------------------- Error Message -------------------------------------------------------------- [0]PETSC ERROR: No support for this operation for this object type [0]PETSC ERROR: Could not determine Plex facet for Gmsh element 1268 (Plex cell 12681) The error seems to come from the fact that the msh file contains tets *and* facets *only on the Physical entities* (aka parts of the mesh boundary where the user will assign Dirichlet or Neuman conditions). If I suppress these facets by commenting the "Physical Surface" lines in the geo file and regenerating the mesh, everything is fine. But the use of these "Physical" stuff is very common in lots of finite element codes in order to assign boundary conditions. How should I do to keep these boundary groups of 2D elements (with corresponding names) ? Thanks for your help, Nicolas
On Tue, May 18, 2021 at 8:18 AM Karin&NiKo <[email protected]> wrote:
Dear PETSc team,
I have tried to load a test mesh available in Gmsh' s demos directory (share/doc/gmsh/demos/simple_geo/filter.geo, attached to this email) as a DMPlex. So I produced a msh4 file by doing : gmsh -3 filter.geo -o /tmp/test.msh4 Then I used src/dm/impls/plex/tutorials/ex2.c to load the mesh by doing : ./ex2 -filename /tmp/test.msh4
Unfortunately I get the error :
[0]PETSC ERROR: --------------------- Error Message -------------------------------------------------------------- [0]PETSC ERROR: No support for this operation for this object type [0]PETSC ERROR: Could not determine Plex facet for Gmsh element 1268 (Plex cell 12681)
The error seems to come from the fact that the msh file contains tets *and* facets *only on the Physical entities* (aka parts of the mesh boundary where the user will assign Dirichlet or Neuman conditions). If I suppress these facets by commenting the "Physical Surface" lines in the geo file and regenerating the mesh, everything is fine.
But the use of these "Physical" stuff is very common in lots of finite element codes in order to assign boundary conditions. How should I do to keep these boundary groups of 2D elements (with corresponding names) ?
Can you also send the *.msh file? I do not have Gmsh on this machine. Thanks, Matt
Thanks for your help, Nicolas
-- 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://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
Sure! I send you both, one with the facets and one without. Thanks, Nicolas Le mar. 18 mai 2021 à 17:49, Matthew Knepley <[email protected]> a écrit :
On Tue, May 18, 2021 at 8:18 AM Karin&NiKo <[email protected]> wrote:
Dear PETSc team,
I have tried to load a test mesh available in Gmsh' s demos directory (share/doc/gmsh/demos/simple_geo/filter.geo, attached to this email) as a DMPlex. So I produced a msh4 file by doing : gmsh -3 filter.geo -o /tmp/test.msh4 Then I used src/dm/impls/plex/tutorials/ex2.c to load the mesh by doing : ./ex2 -filename /tmp/test.msh4
Unfortunately I get the error :
[0]PETSC ERROR: --------------------- Error Message -------------------------------------------------------------- [0]PETSC ERROR: No support for this operation for this object type [0]PETSC ERROR: Could not determine Plex facet for Gmsh element 1268 (Plex cell 12681)
The error seems to come from the fact that the msh file contains tets *and* facets *only on the Physical entities* (aka parts of the mesh boundary where the user will assign Dirichlet or Neuman conditions). If I suppress these facets by commenting the "Physical Surface" lines in the geo file and regenerating the mesh, everything is fine.
But the use of these "Physical" stuff is very common in lots of finite element codes in order to assign boundary conditions. How should I do to keep these boundary groups of 2D elements (with corresponding names) ?
Can you also send the *.msh file? I do not have Gmsh on this machine.
Thanks,
Matt
Thanks for your help, Nicolas
-- 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://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
Okay, what Plex is saying is that Gmsh gave it a facet (a set of vertices), but those are not the vertices of any tetrahedral face in the mesh. It is hard to verify such a thing with 12K tets. I have definitely read in GMsh files before with facets, so I don't think the code is completely wrong. Would it be possible to make a smaller mesh (10-20 cells) that shows the same bug? Thanks, Matt On Tue, May 18, 2021 at 12:25 PM Karin&NiKo <[email protected]> wrote:
Sure! I send you both, one with the facets and one without.
Thanks, Nicolas
Le mar. 18 mai 2021 à 17:49, Matthew Knepley <[email protected]> a écrit :
On Tue, May 18, 2021 at 8:18 AM Karin&NiKo <[email protected]> wrote:
Dear PETSc team,
I have tried to load a test mesh available in Gmsh' s demos directory (share/doc/gmsh/demos/simple_geo/filter.geo, attached to this email) as a DMPlex. So I produced a msh4 file by doing : gmsh -3 filter.geo -o /tmp/test.msh4 Then I used src/dm/impls/plex/tutorials/ex2.c to load the mesh by doing : ./ex2 -filename /tmp/test.msh4
Unfortunately I get the error :
[0]PETSC ERROR: --------------------- Error Message -------------------------------------------------------------- [0]PETSC ERROR: No support for this operation for this object type [0]PETSC ERROR: Could not determine Plex facet for Gmsh element 1268 (Plex cell 12681)
The error seems to come from the fact that the msh file contains tets *and* facets *only on the Physical entities* (aka parts of the mesh boundary where the user will assign Dirichlet or Neuman conditions). If I suppress these facets by commenting the "Physical Surface" lines in the geo file and regenerating the mesh, everything is fine.
But the use of these "Physical" stuff is very common in lots of finite element codes in order to assign boundary conditions. How should I do to keep these boundary groups of 2D elements (with corresponding names) ?
Can you also send the *.msh file? I do not have Gmsh on this machine.
Thanks,
Matt
Thanks for your help, Nicolas
-- 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://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-- 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://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
Dear Matthew, You are (again) right. This Gmsh test file is "dirty" : some triangles do not belong to tests. Sorry for that. I have tried with another geo file (which is clean in that sense) and PETSc reads with no error. I take this opportunity to ask my initial question : are the labels of the Physical Entities saved somewhere ? A gmsh test file with several Physical entities is attached to this email. Thank you again, Nicolas Le mer. 19 mai 2021 à 15:12, Matthew Knepley <[email protected]> a écrit :
Okay, what Plex is saying is that Gmsh gave it a facet (a set of vertices), but those are not the vertices of any tetrahedral face in the mesh. It is hard to verify such a thing with 12K tets. I have definitely read in GMsh files before with facets, so I don't think the code is completely wrong.
Would it be possible to make a smaller mesh (10-20 cells) that shows the same bug?
Thanks,
Matt
On Tue, May 18, 2021 at 12:25 PM Karin&NiKo <[email protected]> wrote:
Sure! I send you both, one with the facets and one without.
Thanks, Nicolas
Le mar. 18 mai 2021 à 17:49, Matthew Knepley <[email protected]> a écrit :
On Tue, May 18, 2021 at 8:18 AM Karin&NiKo <[email protected]> wrote:
Dear PETSc team,
I have tried to load a test mesh available in Gmsh' s demos directory (share/doc/gmsh/demos/simple_geo/filter.geo, attached to this email) as a DMPlex. So I produced a msh4 file by doing : gmsh -3 filter.geo -o /tmp/test.msh4 Then I used src/dm/impls/plex/tutorials/ex2.c to load the mesh by doing : ./ex2 -filename /tmp/test.msh4
Unfortunately I get the error :
[0]PETSC ERROR: --------------------- Error Message -------------------------------------------------------------- [0]PETSC ERROR: No support for this operation for this object type [0]PETSC ERROR: Could not determine Plex facet for Gmsh element 1268 (Plex cell 12681)
The error seems to come from the fact that the msh file contains tets *and* facets *only on the Physical entities* (aka parts of the mesh boundary where the user will assign Dirichlet or Neuman conditions). If I suppress these facets by commenting the "Physical Surface" lines in the geo file and regenerating the mesh, everything is fine.
But the use of these "Physical" stuff is very common in lots of finite element codes in order to assign boundary conditions. How should I do to keep these boundary groups of 2D elements (with corresponding names) ?
Can you also send the *.msh file? I do not have Gmsh on this machine.
Thanks,
Matt
Thanks for your help, Nicolas
-- 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://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-- 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://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
On 19 May 2021, at 14:46, Karin&NiKo <[email protected]> wrote:
Dear Matthew,
You are (again) right. This Gmsh test file is "dirty" : some triangles do not belong to tests. Sorry for that. I have tried with another geo file (which is clean in that sense) and PETSc reads with no error.
I take this opportunity to ask my initial question : are the labels of the Physical Entities saved somewhere ? A gmsh test file with several Physical entities is attached to this email.
Yes, plex represents Physical entities as "labels". In particular, for facets, they are loaded as the "Face Sets" label, plex also loads markers on cells in the "Cell Sets" label. e.g. here's the DMView output of your mesh. DM Object: DM_0x84000000_0 1 MPI processes type: plex DM_0x84000000_0 in 3 dimensions: 0-cells: 64 1-cells: 279 2-cells: 378 3-cells: 162 Labels: celltype: 4 strata with value/size (0 (64), 6 (162), 3 (378), 1 (279)) depth: 4 strata with value/size (0 (64), 1 (279), 2 (378), 3 (162)) Cell Sets: 1 strata with value/size (7 (162)) Face Sets: 6 strata with value/size (3 (18), 6 (18), 2 (18), 5 (18), 1 (18), 4 (18)) Lawrence
Thank you very much Lawrence. Are the names lost or are they saved somewhere ? If I do : "./ex2 -filename /tmp/test/Cube_with_facets.msh4 -dm_view vtk:/tmp/foo.vtk" , I only get the tets of the initial mesh. Thanks, Nicolas Le mer. 19 mai 2021 à 15:49, Lawrence Mitchell <[email protected]> a écrit :
On 19 May 2021, at 14:46, Karin&NiKo <[email protected]> wrote:
Dear Matthew,
You are (again) right. This Gmsh test file is "dirty" : some triangles do not belong to tests. Sorry for that. I have tried with another geo file (which is clean in that sense) and PETSc reads with no error.
I take this opportunity to ask my initial question : are the labels of the Physical Entities saved somewhere ? A gmsh test file with several Physical entities is attached to this email.
Yes, plex represents Physical entities as "labels". In particular, for facets, they are loaded as the "Face Sets" label, plex also loads markers on cells in the "Cell Sets" label.
e.g. here's the DMView output of your mesh.
DM Object: DM_0x84000000_0 1 MPI processes type: plex DM_0x84000000_0 in 3 dimensions: 0-cells: 64 1-cells: 279 2-cells: 378 3-cells: 162 Labels: celltype: 4 strata with value/size (0 (64), 6 (162), 3 (378), 1 (279)) depth: 4 strata with value/size (0 (64), 1 (279), 2 (378), 3 (162)) Cell Sets: 1 strata with value/size (7 (162)) Face Sets: 6 strata with value/size (3 (18), 6 (18), 2 (18), 5 (18), 1 (18), 4 (18))
Lawrence
On 19 May 2021, at 14:57, Karin&NiKo <[email protected]> wrote:
Thank you very much Lawrence. Are the names lost or are they saved somewhere ? If I do : "./ex2 -filename /tmp/test/Cube_with_facets.msh4 -dm_view vtk:/tmp/foo.vtk" , I only get the tets of the initial mesh.
I believe that the mapping of names to integer labels is not maintained in the loading process (you mean this bit, right?): $PhysicalNames 7 2 1 "Surf1" 2 2 "Surf2" 2 3 "Encast" 2 4 "Press" 2 5 "Surf5" 2 6 "Surf6" 3 7 "Vol" $EndPhysicalNames I don't know enough (anything) about the VTK output to know what is output for viz. Lawrence
On Wed, May 19, 2021 at 9:57 AM Karin&NiKo <[email protected]> wrote:
Thank you very much Lawrence. Are the names lost or are they saved somewhere ? If I do : "./ex2 -filename /tmp/test/Cube_with_facets.msh4 -dm_view vtk:/tmp/foo.vtk" , I only get the tets of the initial mesh.
Yes, the names are lost. Jed, Lisandro and Stefano have also asked me about this. I have not done since everything is currently done by number in Plex. It would involve either a) making a separate table in the DM which translates names to numbers or b) putting such a translation table in the DMLabel itself I am putting it off because doing some short is not hard, but getting it to work with everything else would be somewhat of a pain. It would need to distribute properly, propagate to refined/coarsened/subset meshes, etc. which labels currently do. It would not be properly passed on when you just set an int on a point. I think it will happen eventually, but I don't think I have time in the next few weeks. Thanks, Matt
Thanks, Nicolas
Le mer. 19 mai 2021 à 15:49, Lawrence Mitchell <[email protected]> a écrit :
On 19 May 2021, at 14:46, Karin&NiKo <[email protected]> wrote:
Dear Matthew,
You are (again) right. This Gmsh test file is "dirty" : some triangles do not belong to tests. Sorry for that. I have tried with another geo file (which is clean in that sense) and PETSc reads with no error.
I take this opportunity to ask my initial question : are the labels of the Physical Entities saved somewhere ? A gmsh test file with several Physical entities is attached to this email.
Yes, plex represents Physical entities as "labels". In particular, for facets, they are loaded as the "Face Sets" label, plex also loads markers on cells in the "Cell Sets" label.
e.g. here's the DMView output of your mesh.
DM Object: DM_0x84000000_0 1 MPI processes type: plex DM_0x84000000_0 in 3 dimensions: 0-cells: 64 1-cells: 279 2-cells: 378 3-cells: 162 Labels: celltype: 4 strata with value/size (0 (64), 6 (162), 3 (378), 1 (279)) depth: 4 strata with value/size (0 (64), 1 (279), 2 (378), 3 (162)) Cell Sets: 1 strata with value/size (7 (162)) Face Sets: 6 strata with value/size (3 (18), 6 (18), 2 (18), 5 (18), 1 (18), 4 (18))
Lawrence
-- 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://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
Thanks, I think I understand. So at the moment, the user has to manage the link between the labels of the different strata and the names. I am mainly willing to use DMPlex for AMR and names of groups are essential in our code - reading what Mat says gives me the impression that this is doable. Thanks again, Nicolas Le mer. 19 mai 2021 à 16:02, Matthew Knepley <[email protected]> a écrit :
On Wed, May 19, 2021 at 9:57 AM Karin&NiKo <[email protected]> wrote:
Thank you very much Lawrence. Are the names lost or are they saved somewhere ? If I do : "./ex2 -filename /tmp/test/Cube_with_facets.msh4 -dm_view vtk:/tmp/foo.vtk" , I only get the tets of the initial mesh.
Yes, the names are lost. Jed, Lisandro and Stefano have also asked me about this. I have not done since everything is currently done by number in Plex. It would involve either
a) making a separate table in the DM which translates names to numbers
or
b) putting such a translation table in the DMLabel itself
I am putting it off because doing some short is not hard, but getting it to work with everything else would be somewhat of a pain. It would need to distribute properly, propagate to refined/coarsened/subset meshes, etc. which labels currently do. It would not be properly passed on when you just set an int on a point. I think it will happen eventually, but I don't think I have time in the next few weeks.
Thanks,
Matt
Thanks, Nicolas
Le mer. 19 mai 2021 à 15:49, Lawrence Mitchell <[email protected]> a écrit :
On 19 May 2021, at 14:46, Karin&NiKo <[email protected]> wrote:
Dear Matthew,
You are (again) right. This Gmsh test file is "dirty" : some triangles do not belong to tests. Sorry for that. I have tried with another geo file (which is clean in that sense) and PETSc reads with no error.
I take this opportunity to ask my initial question : are the labels of the Physical Entities saved somewhere ? A gmsh test file with several Physical entities is attached to this email.
Yes, plex represents Physical entities as "labels". In particular, for facets, they are loaded as the "Face Sets" label, plex also loads markers on cells in the "Cell Sets" label.
e.g. here's the DMView output of your mesh.
DM Object: DM_0x84000000_0 1 MPI processes type: plex DM_0x84000000_0 in 3 dimensions: 0-cells: 64 1-cells: 279 2-cells: 378 3-cells: 162 Labels: celltype: 4 strata with value/size (0 (64), 6 (162), 3 (378), 1 (279)) depth: 4 strata with value/size (0 (64), 1 (279), 2 (378), 3 (162)) Cell Sets: 1 strata with value/size (7 (162)) Face Sets: 6 strata with value/size (3 (18), 6 (18), 2 (18), 5 (18), 1 (18), 4 (18))
Lawrence
-- 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://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
On Wed, May 19, 2021 at 12:46 PM Karin&NiKo <[email protected]> wrote:
Thanks, I think I understand. So at the moment, the user has to manage the link between the labels of the different strata and the names.
Yes.
I am mainly willing to use DMPlex for AMR and names of groups are essential in our code - reading what Mat says gives me the impression that this is doable.
I think it is. I will be able to do it in the middle of June if you do not have something by then. Can you make an issue? Thanks, Matt
Thanks again, Nicolas
Le mer. 19 mai 2021 à 16:02, Matthew Knepley <[email protected]> a écrit :
On Wed, May 19, 2021 at 9:57 AM Karin&NiKo <[email protected]> wrote:
Thank you very much Lawrence. Are the names lost or are they saved somewhere ? If I do : "./ex2 -filename /tmp/test/Cube_with_facets.msh4 -dm_view vtk:/tmp/foo.vtk" , I only get the tets of the initial mesh.
Yes, the names are lost. Jed, Lisandro and Stefano have also asked me about this. I have not done since everything is currently done by number in Plex. It would involve either
a) making a separate table in the DM which translates names to numbers
or
b) putting such a translation table in the DMLabel itself
I am putting it off because doing some short is not hard, but getting it to work with everything else would be somewhat of a pain. It would need to distribute properly, propagate to refined/coarsened/subset meshes, etc. which labels currently do. It would not be properly passed on when you just set an int on a point. I think it will happen eventually, but I don't think I have time in the next few weeks.
Thanks,
Matt
Thanks, Nicolas
Le mer. 19 mai 2021 à 15:49, Lawrence Mitchell <[email protected]> a écrit :
On 19 May 2021, at 14:46, Karin&NiKo <[email protected]> wrote:
Dear Matthew,
You are (again) right. This Gmsh test file is "dirty" : some triangles do not belong to tests. Sorry for that. I have tried with another geo file (which is clean in that sense) and PETSc reads with no error.
I take this opportunity to ask my initial question : are the labels of the Physical Entities saved somewhere ? A gmsh test file with several Physical entities is attached to this email.
Yes, plex represents Physical entities as "labels". In particular, for facets, they are loaded as the "Face Sets" label, plex also loads markers on cells in the "Cell Sets" label.
e.g. here's the DMView output of your mesh.
DM Object: DM_0x84000000_0 1 MPI processes type: plex DM_0x84000000_0 in 3 dimensions: 0-cells: 64 1-cells: 279 2-cells: 378 3-cells: 162 Labels: celltype: 4 strata with value/size (0 (64), 6 (162), 3 (378), 1 (279)) depth: 4 strata with value/size (0 (64), 1 (279), 2 (378), 3 (162)) Cell Sets: 1 strata with value/size (7 (162)) Face Sets: 6 strata with value/size (3 (18), 6 (18), 2 (18), 5 (18), 1 (18), 4 (18))
Lawrence
-- 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://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-- 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://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
Sure, no problem. Thanks, Nicolas Le mer. 19 mai 2021 à 19:47, Matthew Knepley <[email protected]> a écrit :
On Wed, May 19, 2021 at 12:46 PM Karin&NiKo <[email protected]> wrote:
Thanks, I think I understand. So at the moment, the user has to manage the link between the labels of the different strata and the names.
Yes.
I am mainly willing to use DMPlex for AMR and names of groups are essential in our code - reading what Mat says gives me the impression that this is doable.
I think it is. I will be able to do it in the middle of June if you do not have something by then. Can you make an issue?
Thanks,
Matt
Thanks again, Nicolas
Le mer. 19 mai 2021 à 16:02, Matthew Knepley <[email protected]> a écrit :
On Wed, May 19, 2021 at 9:57 AM Karin&NiKo <[email protected]> wrote:
Thank you very much Lawrence. Are the names lost or are they saved somewhere ? If I do : "./ex2 -filename /tmp/test/Cube_with_facets.msh4 -dm_view vtk:/tmp/foo.vtk" , I only get the tets of the initial mesh.
Yes, the names are lost. Jed, Lisandro and Stefano have also asked me about this. I have not done since everything is currently done by number in Plex. It would involve either
a) making a separate table in the DM which translates names to numbers
or
b) putting such a translation table in the DMLabel itself
I am putting it off because doing some short is not hard, but getting it to work with everything else would be somewhat of a pain. It would need to distribute properly, propagate to refined/coarsened/subset meshes, etc. which labels currently do. It would not be properly passed on when you just set an int on a point. I think it will happen eventually, but I don't think I have time in the next few weeks.
Thanks,
Matt
Thanks, Nicolas
Le mer. 19 mai 2021 à 15:49, Lawrence Mitchell <[email protected]> a écrit :
On 19 May 2021, at 14:46, Karin&NiKo <[email protected]> wrote:
Dear Matthew,
You are (again) right. This Gmsh test file is "dirty" : some triangles do not belong to tests. Sorry for that. I have tried with another geo file (which is clean in that sense) and PETSc reads with no error.
I take this opportunity to ask my initial question : are the labels of the Physical Entities saved somewhere ? A gmsh test file with several Physical entities is attached to this email.
Yes, plex represents Physical entities as "labels". In particular, for facets, they are loaded as the "Face Sets" label, plex also loads markers on cells in the "Cell Sets" label.
e.g. here's the DMView output of your mesh.
DM Object: DM_0x84000000_0 1 MPI processes type: plex DM_0x84000000_0 in 3 dimensions: 0-cells: 64 1-cells: 279 2-cells: 378 3-cells: 162 Labels: celltype: 4 strata with value/size (0 (64), 6 (162), 3 (378), 1 (279)) depth: 4 strata with value/size (0 (64), 1 (279), 2 (378), 3 (162)) Cell Sets: 1 strata with value/size (7 (162)) Face Sets: 6 strata with value/size (3 (18), 6 (18), 2 (18), 5 (18), 1 (18), 4 (18))
Lawrence
-- 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://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-- 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://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
participants (3)
-
Karin&NiKo -
Lawrence Mitchell -
Matthew Knepley