|December 2, 2011, 09:15||
Exporting unstructured, face-based, cell data to VTK
i am writing my own routine to export cell-centered data from an unstructured, polyhedral, FV solver to Paraview writing it in the old legacy VTK format.
The data structure i'm using can handle 2D/3D general polygonal/polyhedral cells and uses a face-based structure; that is, i have the following information:
1) faces belonging to a given cell
2) nodes belonging to a given face (clockwise/counterclockwise ordered)
3) cells sharing a given face
4) cell topology (triangle, quadrilateral,tetrahedron, hexahedron, pyramid, wedge, polygonal/polyhedral)
and i can easily recover also the following information:
4) nodes belonging to a given cell (NOT SORTED IN ANY SPECIFIC ORDER)
Now, i managed to write the exporting routine but, i naively guessed (going against the obvious suggetsions in the figures from http://www.vtk.org/VTK/img/file-formats.pdf and the fact that a face-node information is missing in the file format) that the order for the nodes of the cells was unimportant, that vtk would have managed that somehow.
So, my question is: given my data structure, is there any simple way to order the nodes of a given polyhedral/polygonal cell such that they can be fitted into the numbering scheme provided in the figure 2 of the above link?
Of course, i could hardcode the parts relative to the single cases, but that wouldn't be nice.
Also, i mention that i haven't really read yet the documentation for the XML format. Is there, maybe, a wayout in this format?
|December 7, 2011, 01:41||
This shouldn't be too difficult given you have the face/node information. You simply need to order the faces according to some consistent set of rules. For instance, for a brick element, you will have two +/-X faces, two +/- Y faces, and two +/- Z faces. Of course, these may not actually be aligned with the physical coordinate axis. Then, to make the system consistent, you will likely have to follow into the neighboring cell (you have this info too). A +X face in the first element becomes the -X face in the second, etc...
|December 7, 2011, 05:25||
thank you for your concern. After i spent almost half-day in finding an easy, elegant way to do the job for any kind of cell... i didn't find any possible way. But then i realized that hardcoding the ordering for each kind of cell was not that difficult at all, so i did it.
In practice, what i did is just following the rules described in the link i posted above:
for each cell
for each face of the cell
order the nodes of the face according to the face-normal direction (just in case, not really necessary i think)
if cell=tri/tetra, just put the nodes of the face in the list, endif
if cell=quad/hexa, if it's the first face just put the nodes in the list; endif
if it's not the first face, choose the other face as the one not sharing any node with the first one. Order the nodes of this second face such that the first one/two nodes of the two faces form a face too. Put these nodes in the list. endif
if cell=wedge, take the first tri face and put its nodes in the list;
take the second tri face and order the nodes like in the hexa case; endif
if cell=pyramid, take the quad face and put the nodes in the list;
take the remaining node and put it in the list; endif
if cell=poly, just put the nodes of the face in the list, endif
remove redundant nodes
I tested the program for all but polygonal/polyhedral cells and it works. For polygonal cells (2D) i had to order the cell nodes in a counterclockwise fashion but this was a problem per se. For polyhedral cells there was no obvious way of ordering the nodes. So i just skipped the ordering for poly cells (2D/3D). Also, i don't even have a polyhedral grid generator to test it.
I could also decompose each cell in a sum of tri/tetra and do the job but this would have been much more cumbersome and also the node list should have been augmented by cell and face centroids, which was not so nice.
In any case, thanks
|December 17, 2011, 07:46||
expering data in unstructured mesh
Join Date: Jul 2010
Posts: 38Rep Power: 8
I also tried to export cell data and face data through vtk (legacy) but as per my knowledge volume data and surface data together cannot be exported, only one
but write data in multiple files and read
.xmdf and hdf5
|December 18, 2011, 16:06||
thanks for the interest. Actually, i was not trying to export surface and volume data together but just volume (i.e., cell centered) data. At the end, i managed to write the routine for all but polyhedral cells.
I've read somewhere that, of course, to do the job for polyhedral cells, an additional section is needed in the file, where the face-node connectivity is specified. However i was unable to find anywhere a detailed description of the format for this new section. Also, i am still in doubt if this feature is really available for the old vtk legacy format or it is just available fot the xml one. Are you aware of this or do you have any information about the proper format for polyhedral cells?
|Thread||Thread Starter||Forum||Replies||Last Post|
|How to determine the direction of cell face vectors on processor patches||sebastian_vogl||OpenFOAM Programming & Development||1||October 11, 2016 13:17|
|mesh airfoil NACA0012||anand_30||OpenFOAM Meshing & Mesh Conversion||12||December 12, 2011 05:16|
|How to determine the direction of cell face vectors on processor patches||sebastian_vogl||OpenFOAM Running, Solving & CFD||0||October 27, 2009 09:47|
|Body force at the cell face||Souviktor||Fluent UDF and Scheme Programming||0||March 31, 2009 08:54|
|fluent add additional zones for the mesh file||SSL||FLUENT||2||January 26, 2008 12:55|