Vtk export is broken

[guyer]

As reported in http://thread.gmane.org/gmane.comp.python.fipy/2469, some 3D meshes are not exported cleanly via Vtk.

• Gmsh can't read them (who knew Gmsh could read them in the first place?). At least one issue is that FiPy exports all CellVariable elements as ConvexPointSet cells. Gmsh apparently doesn't know what to do with that (Error : Unknown type of cell 41) and Prabhu has discouraged them. I did it that way originally because it seemed easier than figuring out what every FiPy cell geometry corresponded to in Vtk terms, but I later did all that work for Gmsh anyway (see trunk/fipy/meshes/gmshImport.py@5140#L283 and trunk/fipy/meshes/gmshImport.py@5140#L411 (which should be reconciled)), so probably best to exploit it.

• There seem to be localization problems on some platforms/configurations: the Vtk file is apparently exported with commas instead of periods as the decimal separator, but Gmsh and Mayavi don't understand this. This is particularly confusing in the case of Mayavi, since the export file is written by tvtk and presumably this is what Mayavi is using to read it back in.

  Imported from trac ticket #433, created by guyer on 03-15-2012 at 09:46, last modified: 09-09-2013 at 18:45

[guyer]

_guyer attached twin_ap_3D.msh on 03-15-2012 at 09:48_

[guyer]

guyer attached estat.py on 03-15-2012 at 09:47

[guyer]

These don't seem to be issues under FiPy's control. Although Gmsh can't read the ConvexPointSet cells that FiPy exports, Mayavi, and ParaView can. It would be good to eventually export the more specific cell types when we can, but it's not urgent.

I'm not sure what's to be done about the localization issues. FiPy doesn't actually write the file, it just supplies the data to tvtk.

Trac comment by guyer on 04-10-2012 at 15:40

[guyer]

There's some good information about diagnosing this with pyvista in #693 and pyvista/pyvista-support#108

[amine-aboufirass]

@guyer the issue from https://github.com/pyvista/pyvista-support/issues/108 is not limited to 3D meshes. Consider the following example:

from fipy import CylindricalGrid2D, Grid2D
import pyvista

mesh = Grid2D(dx = 1.0, dy = 1.0, nx = 2, ny = 2)

ugrid= pyvista.UnstructuredGrid(mesh.VTKCellDataSet._vtk_obj)
plotter = pyvista.Plotter()
plotter.set_background('white')
plotter.add_mesh(ugrid, style='wireframe', color='black')
plotter.add_bounding_box(color='red')
plotter.show_grid(color="red")
plotter.view_xy()
plotter.show()

Please also take a look at the following email exchange, credit goes to @wd15 :

It's a possibility, but I suspect it would be a great deal of work. I certainly wouldn't want to tackle it. It maybe easier to just export the correct VTK ordering from FiPy as a separate function that uses the normals to reorder things correctly.

On Thu, Jan 23, 2020 at 2:44 PM A A <> wrote:

Hey Daniel,

If Im reading this correctly then it would not, in theory, break any fipy functionality should the VTK ordering be adopted?

If so, I might be tempted to look into it...

Regards,

Amine

If I'm reading this correctly then the best way forward would be to add a function which readjusts the direction of the normals, rather than than attempting to refactor in order to adopt VTK ordering. Is this correct? If so where should such a function be located?

[guyer]

That's not how I read that, nor is it what I'd do. The FiPy code for exporting VTK is wrong and should be fixed. What Daniel is saying is that the face normals (which FiPy already knows) can be used to figure out what order the exported vertices should be in.