We are trying to use the fairly recent VTK Lagrange cells (specifically, quadrilaterals and hexahedrals). However, some things are not clear to me and I couldn’t find any documentation on it:
Is it possible to specify only point data for such cells or also cell data? If cell data is allowed - how many data values per cell can be added? I assume that they should match the number of points in the cell, but how can one then distinguish between point data and cell data?
How to visualize unstructured, discontinuous data on Lagrange quadrilaterals? Specifically, if I use the same points on an edge that is shared by two quadrilaterals, how to specify values at the boundary from the two adjacent cells? Using “classic” VTK cells, I typically made sure that neighboring cells that share vertices/edges/faces also reuse the same points, since I assume that this is required for VTK to understand the connectivity between cells when calculating gradients etc. However, in case of discontinuous Galerkin solutions, I would lose the ability to specify values at the boundary from each cells, effectively losing some information in the process. Thus, what’s the proper way to go about this?
I apologize if this has been answered before, and if there’s already some form of documentation on these questions, I’d greatly appreciate a reference to it!
Cell Data implies one value per Lagrange cell. You can may use CellData to visualize the cell average of your data. There is no need to use CellData in combination with PointData.
It all depends on whether you want to duplicate points or not in your vtu files. If you do not duplicate points (nodes of the Lagrange cells are unique at element interfaces) then you may observe some artifacts if your simulation data is under-resolved, since you are enforcing continuity. If you duplicate points (nodes of the Lagrange cells are duplicated at element interfaces) then you might see visualizing artifacts related to z-buffering issues
Thanks a lot for your answer! Just to make sure that I understand correctly, even for high-order Lagrange cell, it is only possible to assign a single CellData value to it? If this is true, then there is really no point in using CellData for high-order elements, since this would defeat the whole purpose of having high-quality renderings. Similarly, it does not make sense to use shared points on boundaries for discontinuous Galerkin elements.
However, when not sharing points between elements, doesn’t this adversely affect the capability of ParaView to apply filters that calculate gradients etc.? Z Buffering issues I can also imagine, but what I am more concerned about is, e.g., the ability to compute streamlines etc.
So PointData expects the same number of values than nodes for each cell ((N + 1)^{N_d} per cell where N is the order of the cell). One may use CellData for high-order cells to debug MPI stuff or attributes which are constant within each cell. Some numerical solvers decide to subdivide the cells in a set of linear cells and output the resulting subdivision. With the latter approach it may be interesting to use CellData.
There is no unique solution with regards to the duplication of nodes at element interfaces in high-order elements. Several codes decide to duplicate nodes at element interfaces. The user may then use the filter Clean To Grid to supress duplicated nodes if desired. This approach is easier to implement, it avoids errors in the computation of gradient data but the post-processing files are bigger and all filters run slower.
Yeah, this is what we used before, and it is also less than optimal. For starters, it requires the user to already pick (and fix!) the required resolution for visualization during pre-processing (i.e., when converting the original solution files to VTU files). Also, for really high-order cells, it quickly blows up the file size since you often need twice the amount of linear cells as you have degrees of freedom in your high-order solution. This is in fact the main reason why we are thinking about switching to VTK_LAGRANGE_QUADRILATERAL/VTK_LAGRANGE_HEXAHEDRAL.