I’ve been reading about the latest improvements to Paraview to support DG solution fields, where there can be multiple control fields for a given point in the mesh:
I’m interested in trying this new functionality, as my research is in DG methods. Has anyone tried this before, or could give a few pointers on trying a simple example? As I understand it, only the Exodus reader is supported at present?
I’m not sure if I should ask this question on the “development” side instead, feel free to let me know if so.
@Sam_Austin Thanks for your interest! Sorry for the slow reply.
There are two file formats supported: Exodus and a simple JSON format used for testing. I would recommend looking at the JSON example data first as it should make the in-memory model of vtkCellGrid more clear than the Exodus format.
For example, the simple example files attached contain a few cells per file and illustrate how vtkDGCell models geometry
as a series of vtkDataSetAttributes instances that group arrays (in the arrays section of the JSON file);
as a series of vtkCellAttribute instances (defined in the attributes section of the JSON file, and which reference arrays in the arrays section); and finally
as a series of vtkCellMetadata instances (defined in the cell-types section of the JSON) that define cells by referencing a connectivity array plus a shape.
You can load them in ParaView, but also edit them by hand and modify them. Besides the ASCII-formatted JSON, VTK’s cell-grid readers/writers can use the binary MessagePack format that nlohmann::json can generate.
Also, if you are comfortable building VTK and one of its examples, this example will show you an editable, spreadsheet-like view of single cells of different shapes.
If you have more specific questions (perhaps Exodus-related if your data outgrows the JSON format), please feel free to ask! I would be happy to see vtkCellGrid get some exercise.
Hi @dcthomp, thanks for your reply! I have been meaning to build VTK and run the examples but have not had the time yet. In the meantime, I wanted to ask a follow up question. First, let me describe my DG use case. I am considering the HDG (Hybridized-DG) FE method. A powerful feature of this method is that it doesn’t require the other spaces in the de Rham complex like H(curl) etc to model E&M and other physics. This means that I am working with fairly vanilla isoparametric L2 elements, where the same nodes used to represent the solution also represent the geometry.
The implication for my visualization task is that I need to specify duplicate values for points along element boundaries. I did some more digging, and found that support for what I need may have already been implemented in ParaView 5.11, with the “Finite Element Field Distributor” (I noticed you mentioned this in a blog post in 2022):
Do you think this would be an appropriate solution in the near term? And similarly to my first question, is this only supported by the Exodus reader at present? I have to admit that my current workflow is fairly basic: I am using PyVista in Python to deal with the heavy lifting of converting my numpy arrays to .VTU files. In the future, however, I will be scaling my Python prototype implementation to C++ and will then need to work with VTK directly. I’m just trying to get an understanding of the workflow in order to use this DG visualization feature in ParaView.
It is exciting to see development in these visualization technologies to support novel high order discretizations! In the past, my workflow always involved projecting onto a mesh with continuous H1 elements, but these new workflows should require less visualization preprocessing as well as reproduce the solution more faithfully.
While you can use the Finite Element Field Distributor (FEFD), it comes with the cost of duplicating vertices shared by multiple cells so that the older vtkUnstructuredGrid data structure can be used. (So, if 5 cells are incident to a point, that point will duplicated 5 times in the output mesh so that it can take on a different value for each cell.) The newer vtkCellGrid data structure does not require duplicated point coordinates to represent the same mesh with discontinuities. ParaView 5.13.1+ come with Exodus and JSON support for vtkCellGrid. My post above provided JSON examples.
Exodus
The Exodus file format support is in flux because the goal is to support both continuous (CG) and discontinuous (DG) fields on the same mesh.
The current support uses Exodus’ info_records capability to annotate sets of variables on blocks as corresponding to Lagrange coefficients. In this scheme, fields that are discontinuous are represented with N element-block variables (where N is the number of Lagrange shape functions per cell). This works great for DG but duplicates values on shared vertices/edges/faces of CG fields.
The next Exodus (and IOSS) specification supports both (a) direct representation of Lagrange coefficients rather than special treatment of element-block variables and (b) degree-of-freedom sharing for coefficients appearing on cell boundaries. In this scheme, Exodus edge blocks and face blocks (rather than element blocks) may hold Lagrange coefficients on faces/edges of elements. However, VTK/ParaView do not support the new Exodus/IOSS specification because there are some issues to work out with arbitrary-order elements and connectivity.
We do not have funding for (2) above yet, but (1) is supported.
The info_records data in an Exodus file that wants DG support for fields named electron_P (pressure), electron_p (momentum, a vector), and electron_u (velocity, a vector) should look like this example:
Each line is a separate record. The double colons (::) separate fields within each record.
The first record declares that block_1 (the name of an element block) has HGRAD fields (as opposed to HCURL/HDIV) defined using the Intrepid2 basis functions for C1 finite elements. These are traditional Lagrange basis functions.
The next 7 records name specific fields whose values should be used as DG coefficients rather than cell-constant fields.
The final 2 records indicate that the momentum (p{x,y,z}) and velocity (u{x,y,z}) fields should be combined into vectors rather than be treated as scalars. Because these info_records annotations will be phased out once the new enhanced field metadata support is in, I’m not sure I would recommend using it for now.
Hi @dcthomp, thanks for your quick reply and for these tips! I will take a look at applying the workflow to a representative dataset and let you know how it goes. Good to know that Exodus and JSON support for vtkCellGrid has been in PV since 5.13.1.
