VTK XML export

[KristofferC]

I have written code for VTKXML-export for my finite element simulations in Julia. It should not be too hard to adapt them to work for this mesh type.

Would that be of interest?

I will probably not write a VTK reader since, from what I know, VTK is almost exclusively used for post processing.

In my code I use the LightXML package for the XML stuff and Zlib for the compression. Maybe it is undesireable to have these two as required packages?

Comments?

[SimonDanisch]

It's definitely of interest. What also would be interesting is to integrate the mesh type that you're using!
If you then define convert function to HomogenousMesh, you can visualize your meshes with GLVisualize.
Using unnecessary packages is undesired but fine, if it makes coding easier. You could just include them via Requires.jl, so they're only loaded if you actually export a vtk file.
It might be worth looking at the VTK export approaches used over at JFinEALE.jl and WriteVTK.

Best,
Simon

[KristofferC]

Well, I don't like the mesh format I use right now and I am actively looking to change it.

I've been looking at two representations in particular.

The first and a bit simpler by Logg:
http://arxiv.org/pdf/1205.3081.pdf

@mauro3 has started implementing it here but it is a bit unfinished:
https://bitbucket.org/maurow/mesh.jl/

He said on the mailing list that he might continue it at some point.

There is also a more advanced one, which is used by PETSC:
http://www.mcs.anl.gov/petsc/documentation/tutorials/sieve.pdf

From what I know JFinEALE only supports exopot to the older VTK legacy format which is simpler but only supports ASCII. VTKXML supports some more advanced features like binary data and compression.

WriteVTK is quite similar to what I have written but it doesn't seem to support unstructured meshes?

Regarding the HomogeneousMesh type, if I want to convert a heterogeneous mesh to it (for example one that contains both triangles and rectangles), should I make two separate HomogeneousMeshes, one with the triangles and one with the squares?

[SimonDanisch]

For the GPU, everything must be converted to triangles in the end, and one
big mesh is faster to draw than many small meshes -> convert them both to
triangles ;)

2015-05-01 16:33 GMT+02:00 Kristoffer Carlsson [email protected]:

Well, I don't like the mesh format I use right now and I am actively
looking to change it.

I've been looking at two representations in particular.

The first and a bit simpler by Logg:
http://arxiv.org/pdf/1205.3081.pdf

@mauro3 https://github.com/mauro3 has started implementing it here but
it is a bit unfinished:
https://bitbucket.org/maurow/mesh.jl/

He said on the mailing list that he might continue it at some point.

There is also a more advanced one, which is used by PETSC:
http://www.mcs.anl.gov/petsc/documentation/tutorials/sieve.pdf

From what I know JFinEALE only supports exopot to the older VTK legacy
format which is simpler but only supports ASCII. VTKXML supports some more
advanced features like binary data and compression.

WriteVTK is quite similar to what I have written but it doesn't seem to
support unstructured meshes?

Regarding the HomogeneousMesh type, if I want to convert a heterogeneous
mesh to it (for example one that contains both triangles and rectangles),
should I make two separate HomogeneousMeshes, one with the triangles and
one with the squares?

—
Reply to this email directly or view it on GitHub
#1 (comment).

[KristofferC]

Ok, makes sense.

VTK has this notion of CellData and PointData. CellData are values defined on a cell, for example a triangle, where PointData is defined on the vertices of a cell. Do you plan on having such a distinction? I guess it is not strictly needed since you can convert CellData to PointData by taking the average of the values in the cells surrounding a point.

[mauro3]

I remember that I found the Sieve paper hard to understand (i.e. I did not understand it), thus I went for the Logg-mesh.

Just as a datapoint: in my application I need to be able to separately display values on edges and PointData.

[SimonDanisch]

I would need to know, what the difference in the visualization is. Than I need to know, if there are datatypes that represent this difference, while being able to directly translate into OpenGL calls.
What you mention seems to be more of a higher level abstraction, which needs a more complicated translation in order to get it visualized via OpenGL. So for visualization purposes, it probably doesn't make sense to make this distinction inside a mesh type.
Please consider opening issues at GLVisualize, which describe your data and your target visualization.
This way we can keep track of what is actually wanted and how the data looks like and then discuss concrete examples and implementations.

[jipolanco]

Hi, I'm the author of WriteVTK.jl. The code currently only supports writing VTK StructuredGrid files (.vts) and multiblock files (.vtm). The files are written in XML format (using LightXML as well), and data can be compressed with Zlib. I guess it wouldn't be too difficult to add support for unstructured grids though.

[SimonDanisch]

Awesome =) Well, I will clean up the FileIO api a little, today or tomorrow... You should probably wait for this!

[SimonDanisch]

I will address ambiguities of file endings, and a cleaner architecture.

[SimonDanisch]

well I guess, one could just try to start porting this... Refactoring won't be huge, and the biggest bit of work will be, to guarantee that all mesh loaders have the same functionality, like just parsing the wanted attributes, already in the correct format (Like described in the MeshIO readme).
I've opened an issue over at FileIO, to discuss the general architecture: JuliaIO/FileIO.jl#13