Higher order visualizations
mortezah opened this issue · comments
Due to increased involvement with high-order fem codes, I guess it would be worthwhile to extend/improve high-order visualization APIs in SCOREC/Core.
At the moment we support high-order mesh visualization via the two APIs crv::writeCurvedVtuFiles (which creates tesselations of mesh tets or tris) and crv::writeCurvedWireFrame (which tesselation of mesh edges). And we don't have any simple way of visualizing high-order solution fields.
According to this (https://blog.kitware.com/modeling-arbitrary-order-lagrange-finite-elements-in-the-visualization-toolkit/) Kitware blogpost, VTK now supports arbitrary order Lagrange elements.
An example ASCII VTU file with higher order elements and fields is shown below (can also be downloaded from here
https://data.kitware.com/#collection/5a4560018d777f5e872f779e).
<VTKFile type="UnstructuredGrid" version="1.0" byte_order="LittleEndian" header_type="UInt64">
<UnstructuredGrid>
<Piece NumberOfPoints="72" NumberOfCells="5">
<PointData>
<DataArray type="Float32" Name="Ellipsoid" format="ascii">
0 0 0 0
0 0 0 0
1 1 1 1
1 1 1 1
1 1 1 1
2 2 2 2
2 2
3
0 0 0 0
1 1 1 1
1 1 1 1
3 2 2 2
2
5
0 0 0 0
1 1 1 1
2
0 0
1 1 1
2
0 0
1
0 0
1 1 1 1 1
2 2 2
</DataArray>
</PointData>
<CellData>
<DataArray type="Float32" Name="SrcCellNum" format="ascii">
0 1 2 3 4
</DataArray>
</CellData>
<Points>
<DataArray type="Float32" Name="Points" NumberOfComponents="3" format="ascii">
0 0 0
4 0 0
4 4 0
0 4 0
0 0 4
3.5 0 4.5
4.5 4.5 4.5
0 4 4
2 0 0
4 2 0
2 4 0
0 2 0
2 0 4
4 2 4
2 4 4
0 2 4
0.5 0.5 2
4 0 2
0 4 2
4 4 2
0 2 2
4 2 2
2 0 2
2 4 2
2 2 0
2 2 4
2 2 2
8 0 0
8 4 0
8 0 4
8 4 4
6 0 0
8 2 0
6 4 0
6 0 4
8 2 4
6 4 4
8 0 2
8 4 2
8 2 2
6 0 2
6 4 2
6 2 0
6 2 4
6 2 2
-1 0 0
-1 4 0
-1 4 4
-1 0 4
-1 2 0
-1 4 2
-1 2 4
-0.5 0.5 2
-1 2 2
4 -1 0
3.5 -1 4.5
2 -1 0
4 -1 2
2 -1 4
2 -1 2
0 -1 0
0 -1 4
0 -0.5 2
12 0 2
12 4 2
10 0 1
12 2 2
10 4 1
10 0 3
10 4 3
10 2 1
10 2 3
</DataArray>
</Points>
<Cells>
<DataArray type="Int64" Name="connectivity" format="ascii">
0 1 2 3
4 5 6 7
8 9 10 11
12 13 14 15
16 17 18 19
20 21 22 23 24 25
26
1 27 28 2
5 29 30 6
31 32 33 9
34 35 36 13
17 37 19 38
21 39 40 41 42 43
44
45 46 47 48
49 50 51 52
53
60 54 55 61
56 57 58 62
59
27 63 29 28 64 30
65 68 37
67 69 38
32 66 35
70 71 39
</DataArray>
<DataArray type="Int64" Name="offsets" format="ascii">
27 54 63 72 90
</DataArray>
<DataArray type="UInt8" Name="types" format="ascii">
72 72 70 70 73
</DataArray>
</Cells>
</Piece>
</UnstructuredGrid>
</VTKFile>
Loading that file into Paraview (version 5.8.x) produces the following pictures
- top-left: loaded into ParaView with no tessellation
- top-right: loaded into ParaView and tessellated the edges [using the "Tessellate" filter in ParaView]
- bottom-right: loaded into ParaView and tessellated the faces [using the "Tessellate" filter in ParaView]
This looks promising. Good find 👍 . Are there any drawbacks vs. the current approach?
There is no drawback when compared to the current approach.
It makes things a lot cleaner though. For example we won't need two different outputs to load to paraview anymore, for curved meshes.
Both approaches are supposed to create large files.
@KennethEJansen mentioned in a call today that several filters (slice, contour, etc.) revert back to linear elements with some of the higher order element types. I'm not sure if the same element types were being used in both cases.
edit: @KennethEJansen also pointed out that there are bezier elements listed here:
https://vtk.org/doc/nightly/html/classvtkCell.html