breaking changes?

[nschloe]

It's been a while since the last breaking change in meshio, but I'm contemplating some. I'm looking for opinions and new ideas.

• Right now, there are three methods for writing out a mesh:

  meshio.write_points_cells(filename, points, cells, ...)
  
  mesh = meshio.Mesh(points, cells, ...)
  meshio.write(filename, mesh)
  
  mesh.write(filename)

  The last two are redundant. I'm thinking about removing the second option, and rename write_points_cells to write. Shorter, better.

[keurfonluu]

I agree. Same for meshio.Mesh.read, I think it can be removed as it is more convenient to use meshio.read.

[gdmcbain]

The last two are redundant.

It is very common in the ecosystem to have this kind of redundancy; e.g.

• numpy.reshape
• numpy.ndarray.reshape

Advantages of the method over the function include discoverability: a meshio.Mesh might be returned by a function from some other module, e.g.

https://github.com/nschloe/pygmsh/blob/e942d38d59ee3d0001ed1c12688b3facc3e3b08f/pygmsh/helpers.py#L117

which could be interrogated (at the REPL via dir(mesh) or automatically in one of the nice modern IDEs). Another is that one doesn't then have to import meshio.write; the method is directly available.

[gdmcbain]

rename write_points_cells to write

I'm not overly enthusiastic about this one either; having one function do multiple different things depending on the number or type of arguments increases cyclomatic complexity and reduces readability.

[krober10nd]

One thing I always found confusing about write_points_cells is that the cells has be passed as a list of tuples with the word "tetra".

meshio.write_points_cells(
    "mesh.vtk",
    points,
    [("tetra", cells)],
)

It would be simpler if you could just:

meshio.write('mesh.vtk',points,cells);

[keurfonluu]

One thing I always found confusing about write_points_cells is that the cells has be passed as a list of tuples with the word "tetra".

Well, meshio deals with meshes that are not necessarily tetrahedral. It can be hexahedral or even mixed. You can't simply guess the nature of the cell from the shape of the array (e.g., quads and tetras have the same numbers of nodes). Or maybe I missed your point.

[krober10nd]

Yes, I realize that there are many kinds of meshes handled by meshio and I'm not suggesting to necessarily get rid of how it works but for some meshes, the shapes of the cells and points is unique (and some of the most common I'd imagine, i.e., triangles, tetrahedrals). In those case, I would welcome a simpler interface for the cells arg.

[nschloe]

tetra has 4 points per cell just like quad has. triangle has 3 just like line2. I'm not sure if there are any cells for which the number of points is unique, so we'll probably have to keep a string keyword here somewhere.

[krober10nd]

For sure. But a tetra has four points in 3 dimensions a quad has the same in 2d. Surface meshes I agree are a different story. Anyway I retract my suggestion based on your explanations.

On Sat, 30 Jan 2021 at 9:52 AM Nico Schlömer ***@***.***> wrote: tetra has 4 points per cell just like quad has. triangle has 3 just like line2. I'm not sure if there are any cells for which the number of points is unique, so we'll probably have to keep a string keyword here somewhere. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1001 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEOBZ7BSIV2EATLGE3GBP2TS4P6INANCNFSM4VYXKJHA> .

-- Keith Jared Roberts ([email protected]) Postdoctoral Research Fellow Escola Politécnica, Universidade de São Paulo keithroberts.site

[nschloe]

But a tetra has four points in 3 dimensions a quad has the same in 2d. Surface meshes I agree are a different story.

Right, there is no distinction between a surface and a non-surface mesh. quads, tets etc can occur in any spatial dimension.