Importing a mesh XML file seems to alter the order of the nodes in a triangle?

Question

Ok - I have a semi-large XML file that I generate outside of FEniCS. The mesh file loads and plots without FEniCS complaining about it, and it does indeed look like I wanted it to look in the plot command. However, it appears that the order of the nodes gets altered during import. An example triangle tag in the file is:

<triangle index="46" v0="49" v1="43" v2="46" />

However, if inside of the script, I ask it for the nodes the make up cell 46, I get:

mesh = Mesh("stuff.xml.gz")
mesh.cells()[46]
array([43, 46, 49], dtype=uint32)

I was wondering if there was some way to import the mesh without having anything done to the node ordering, since I have a couple of mesh function files that I am loading, and one of them depends on the order of the edges in the cells being left alone.

I am using the OS X 10.7 snapshot from yesterday (17-Nov-2013).

Answer 1

The Mesh should be ordered accordingly with the UFC numbering, which is in ascending order for it to comply with the FEniCS pipeline. If the Mesh is not ordered according to the UFC numbering it will be ordered during construction. I do not think you can avoid that.

I think the best you can do is to order the connectivity before you write it to file, and then sort your edge information accordingly. I think there are some external mesh formats in meshconverter.py that do that already.

Comments

Ok - tried this in Exodus II:

Converting from Exodus II format to NetCDF format
Traceback (most recent call last):
  File "/Applications/FEniCS.app/Contents/Resources/bin/dolfin-convert", line 131, in <module>
    main(sys.argv[1:])
  File "/Applications/FEniCS.app/Contents/Resources/bin/dolfin-convert", line 78, in main
    meshconvert.convert2xml(ifilename, ofilename, iformat=iformat)
  File "/Applications/FEniCS.app/Contents/Resources/lib/python2.7/site-packages/dolfin_utils/meshconvert/meshconvert.py", line 1291, in convert2xml
    convert(ifilename, XmlHandler(ofilename), iformat=iformat)
  File "/Applications/FEniCS.app/Contents/Resources/lib/python2.7/site-packages/dolfin_utils/meshconvert/meshconvert.py", line 1336, in convert
    exodus2xml(ifilename, ofilename)
  File "/Applications/FEniCS.app/Contents/Resources/lib/python2.7/site-packages/dolfin_utils/meshconvert/meshconvert.py", line 1277, in exodus2xml
    raise IOError, "Something wrong while executing ncdump. Is ncdump "\
IOError: Something wrong while executing ncdump. Is ncdump installed on the system?

tim@shiny:Stuff$ which ncdump
/Users/tim/bin/ncdump

Next - tried after running ncdump myself:

tim@shiny:Stuff$ dolfin-convert test.ncdf test.xml
Converting from NetCDF format (.ncdf) to DOLFIN XML format
Expecting 16 cells
Traceback (most recent call last):
  File "/Applications/FEniCS.app/Contents/Resources/bin/dolfin-convert", line 131, in <module>
    main(sys.argv[1:])
  File "/Applications/FEniCS.app/Contents/Resources/bin/dolfin-convert", line 78, in main
    meshconvert.convert2xml(ifilename, ofilename, iformat=iformat)
  File "/Applications/FEniCS.app/Contents/Resources/lib/python2.7/site-packages/dolfin_utils/meshconvert/meshconvert.py", line 1291, in convert2xml
    convert(ifilename, XmlHandler(ofilename), iformat=iformat)
  File "/Applications/FEniCS.app/Contents/Resources/lib/python2.7/site-packages/dolfin_utils/meshconvert/meshconvert.py", line 1333, in convert
    netcdf2xml(ifilename, ofilename)
  File "/Applications/FEniCS.app/Contents/Resources/lib/python2.7/site-packages/dolfin_utils/meshconvert/meshconvert.py", line 1208, in netcdf2xml
    n0 = int(connect[0])-1
ValueError: invalid literal for int() with base 10: ''

I am running the snapshot from two days ago, and I'll see if I can figure out what it didn't like .

---

Not sure what you want with your post. If you want me to help you you need to provide more information about what you did and the files you tried to convert.

Have in mind that dolfin-convert is a community driven script that unfortunately keeps breaking as the interface of dolfin keep changing. There are too few unit tests that covers that script. If you discovers a bug it is probably best to try to contact the author of the particular conversion that is broken or try fixing it your self.

Also I did not suggest you to use dolfin-convert directly. I meant to suggest you to take a look into how some of the backends, like gmsh I think, reorders the vertex information according to UFC ordering, while also updating facet information.