search

thegooglecodearchive / sfepy

Automatically exported from code.google.com/p/sfepy
0 stars 0 forks source link

Troubles loading vtk mesh file #95

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 

I am trying to load a mesh written by gmesh (see attached) but it fails
because the first cell in the cells list is type 1, causing 
    vtk_dims[cell_types[0,0]]
raise a KeyError in meshio.py as 
    vtk_dims = {3 : 2, 9 : 2, 5 : 2, 3 : 3, 10 : 3, 12 : 3}
does not handle single point cells.
I don't know is these single point cells are a bug in gmesh or a feature
that sfepy does not care about.

Original issue reported on code.google.com by Fabrice....@gmail.com on 13 Aug 2009 at 2:47

Attachments:

GoogleCodeExporter commented 9 years ago 
SfePy currently supports only triangles, quads, tetrahedrons and hexahedrons. 
What
are those single point cells used for? Would it be enough to modify the mesh 
reader
so that it ignores the unknown cell types?

Original comment by robert.c...@gmail.com on 13 Aug 2009 at 2:53

GoogleCodeExporter commented 9 years ago 
One more thing - your mesh is a 3D surface (nice!), but in 3D, sfepy needs a 
volume
mesh (e.g. of tetrahedrons).

Original comment by robert.c...@gmail.com on 13 Aug 2009 at 3:07

GoogleCodeExporter commented 9 years ago 
I don't know why Gmesh adds those singular cells in vtk file and not in the 
other
formats it supports (msh and medit for example).
Would it be difficult not to load them ? 
Just an idea : in VTKMeshIO.read, when the 'while 1' loop ends, pop the lines 
of the
array that has undesirable value in the first column, count the dropped cells 
and
adjust n_el and n_val

Original comment by Fabrice....@gmail.com on 13 Aug 2009 at 3:08

Attachments:

GoogleCodeExporter commented 9 years ago 
You are right about the 3D surface, but I have the same problem with a 3D 
volume mesh
(see cylindre.vtk). I attached in the original bugreport a lightweight vtk file
showing singular cells that the sfepy does not handle.

Original comment by Fabrice....@gmail.com on 13 Aug 2009 at 3:12

Attachments:

GoogleCodeExporter commented 9 years ago 
I can now read the mesh, but there are also some line segment cells - the 
computation
will not work with that (no bar elements in sfepy), so we should probably 
ignore any
cells besides those with the highest dimension.

Original comment by robert.c...@gmail.com on 13 Aug 2009 at 3:25

GoogleCodeExporter commented 9 years ago 
Try the attached patch, please.

Original comment by robert.c...@gmail.com on 13 Aug 2009 at 3:30

Attachments:

GoogleCodeExporter commented 9 years ago 
With the patch, calling Mesh.from_file (in problemDef) does not raise the 
KeyError
anymore. Thanks!

Original comment by Fabrice....@gmail.com on 13 Aug 2009 at 3:40

GoogleCodeExporter commented 9 years ago 
Good, here is a better patch. If all works, you can close the issue :)

Original comment by robert.c...@gmail.com on 13 Aug 2009 at 3:59

Attachments:

GoogleCodeExporter commented 9 years ago 
It seems to work too. At least it loads the mesh file without raising any error.

Original comment by Fabrice....@gmail.com on 13 Aug 2009 at 4:48

GoogleCodeExporter commented 9 years ago 
Good, let's close this.

Original comment by robert.c...@gmail.com on 14 Aug 2009 at 8:29

GoogleCodeExporter commented 9 years ago 
Migrated to http://github.com/sfepy/sfepy/issues/97

Original comment by robert.c...@gmail.com on 30 Jan 2012 at 10:26