# Discontinuous Galerkin Support in Paraview
**URL:** https://discourse.paraview.org/t/discontinuous-galerkin-support-in-paraview/16132
**Category:** ParaView Support
**Created:** [February 9, 2025, 6:35am UTC](https://discourse.paraview.org/t/discontinuous-galerkin-support-in-paraview/16132 "2025-02-09T06:35:14Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@Sam\_Austin](https://discourse.paraview.org/u/Sam_Austin)
#### Post date: [February 9, 2025, 6:35am UTC](https://discourse.paraview.org/t/discontinuous-galerkin-support-in-paraview/16132/1 "2025-02-09T06:35:14Z")
Hi there,
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:
[https://gitlab.kitware.com/paraview/paraview/-/issues/21120](https://gitlab.kitware.com/paraview/paraview/-/issues/21120)
[https://gitlab.kitware.com/vtk/vtk/-/merge\_requests/10356](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10356)
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.
Best,
Sam
---
### Author:  [@Lucas\_Givord](https://discourse.paraview.org/u/Lucas_Givord)
#### Post date: [February 10, 2025, 7:43am UTC](https://discourse.paraview.org/t/discontinuous-galerkin-support-in-paraview/16132/2 "2025-02-10T07:43:42Z")
Hello @Sam_Austin,
I believe @dcthomp or @Charles_Gueunet could help you here 🙂
---
### Author:  [@dcthomp](https://discourse.paraview.org/u/dcthomp)
#### Post date: [February 12, 2025, 7:07pm UTC](https://discourse.paraview.org/t/discontinuous-galerkin-support-in-paraview/16132/3 "2025-02-12T19:07:23Z")
@Sam_Austin Thanks for your interest! Sorry for the slow reply.
> [@Sam\_Austin](#):
>
> Has anyone tried this before, or could give a few pointers on trying a simple example?
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.
[cellgrid-examples.zip](https://discourse.paraview.org/uploads/short-url/l5QxzB68iLiC625w5LYi9MJ5kYk.zip) (22.9 KB)
For example, the [simple example files](https://discourse.paraview.org/uploads/short-url/l5QxzB68iLiC625w5LYi9MJ5kYk.zip) 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](https://msgpack.org/) format that `nlohmann::json` can generate.
Also, if you are comfortable building VTK and one of its examples, [this example](https://gitlab.kitware.com/vtk/vtk/-/tree/master/Examples/GUI/Qt/CellGridSource?ref_type=heads) 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.
---
### Author:  [@Sam\_Austin](https://discourse.paraview.org/u/Sam_Austin)
#### Post date: [February 19, 2025, 4:11am UTC](https://discourse.paraview.org/t/discontinuous-galerkin-support-in-paraview/16132/4 "2025-02-19T04:11:05Z")
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):
- [Discontinuous Galerkin elements and other novel cell-types/function-spaces - Development - VTK](https://discourse.vtk.org/t/discontinuous-galerkin-elements-and-other-novel-cell-types-function-spaces/9209)
- [https://www.paraview.org/paraview-docs/latest/cxx/md\_\_builds\_gitlab-kitware-sciviz-ci\_Documentation\_release\_ParaView-5\_811\_80.html](https://www.paraview.org/paraview-docs/latest/cxx/md__builds_gitlab-kitware-sciviz-ci_Documentation_release_ParaView-5_811_80.html)
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.
---
### Author:  [@dcthomp](https://discourse.paraview.org/u/dcthomp)
#### Post date: [February 19, 2025, 5:11am UTC](https://discourse.paraview.org/t/discontinuous-galerkin-support-in-paraview/16132/5 "2025-02-19T05:11:34Z")
## FEFD
> [@Sam\_Austin](#):
>
> … 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) …
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.
1. 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.
2. The next Exodus (and IOSS) specification supports both (a) [direct representation of Lagrange coefficients](https://github.com/sandialabs/seacas/wiki/Enhanced-Field-Metadata-(was-Discontinuous-Galerkin)) 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:
```txt
"HGRAD::block_1::DG::basis::Intrepid2_HGRAD_HEX_C1_FEM",
"HGRAD::block_1::DG::field::electron_P",
"HGRAD::block_1::DG::field::electron_px",
"HGRAD::block_1::DG::field::electron_py",
"HGRAD::block_1::DG::field::electron_pz",
"HGRAD::block_1::DG::field::electron_ux",
"HGRAD::block_1::DG::field::electron_uy",
"HGRAD::block_1::DG::field::electron_uz",
"HGRAD::block_1::DG::fieldglom::electron_p::x,y,z",
"HGRAD::block_1::DG::fieldglom::electron_u::x,y,z",
```
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](https://github.com/trilinos/Trilinos/blob/master/packages/intrepid2/src/Discretization/Basis/) 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.
---
### Author:  [@Sam\_Austin](https://discourse.paraview.org/u/Sam_Austin)
#### Post date: [February 19, 2025, 8:50pm UTC](https://discourse.paraview.org/t/discontinuous-galerkin-support-in-paraview/16132/6 "2025-02-19T20:50:36Z")
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.
---
### Author:  [@Sam\_Austin](https://discourse.paraview.org/u/Sam_Austin)
#### Post date: [September 11, 2025, 5:18pm UTC](https://discourse.paraview.org/t/discontinuous-galerkin-support-in-paraview/16132/7 "2025-09-11T17:18:12Z")
Hi @dcthomp, I wanted to drop in with an update. I have been able to get vtkCellGrid working for my DG visualization workflow in Paraview using the JSON file format. However, I have a question about the specification of vector fields for CellGrids. The JSON examples that you included in the .zip file above all use the “shape” field as an example vector field. However, I would like to implement a simple example of a discontinuous vector field in the same manner as the scalar fields, i.e. duplicated vector values on the boundaries of elements.
My test is straightforward: I copied the “dg points” array, duplicated nodes and permuted it it to match the element connectivity. I then made a new 3-component attribute named “Vect”, similar to the “shape” attribute, and referenced the array that I just created.
Paraview will load the file and the new “Vect” field appears to match the “shape” fields (which is what I intended). However, I am getting a warning that the number of components in the vector field is incorrect:
Warning: In vtkDataSetAttributes.cxx, line 1710
vtkDataSetAttributes (0x4446f260): Can not set attribute Vectors. Incorrect number of components.
Even though this example works, I am asking here because I am concerned that the file has a subtle mis-specification that will come back to bite later. I attach my modified “dgQuadraticQuadrilateralsWithVectors.dg” file; would you mind taking a look and letting me know what is wrong?
Thanks,
Sam
[dgQuadraticQuadrilateralsWithVectors.dg](https://discourse.paraview.org/uploads/short-url/vErtFkQ8m1Kb3dLVwOVxEL4EBdy.dg) (5.5 KB)
---
### Author:  [@dcthomp](https://discourse.paraview.org/u/dcthomp)
#### Post date: [September 11, 2025, 7:46pm UTC](https://discourse.paraview.org/t/discontinuous-galerkin-support-in-paraview/16132/8 "2025-09-11T19:46:53Z")
@Sam_Austin Two things:
1. You should remove `"default_vectors": true,` from line 105. The bag of arrays (a vtkDataSetAttributes instance) named `vtkDGQuad` does not need a default vector array. For discontinuous fields, the number of components per tuple should be the product of the number of coefficients per DOF (3) times the number of DOF per element (9), which is 27 for the quadratic quad. As you noticed, vtkDataSetAttributes will refuse to accept arrays to be the “active vectors” unless the number of components is 6 or 9. I have this change eliminates the warning.
2. You should probably remove `"connectivity": ["vtkDGQuad", "conn"]` from line 160. Because you are describing a field with discontinuous elements there is no need to map vector values from shared degrees of freedom. If `vect` was a continuous field that shared vector values on cells with common boundaries, you would need `connectivity`. I have taken to removing this line from other discontinuous cell-attribute specifications. It is not currently a problem for it to be there; it will simply be ignored. But it is better to eliminate it.
---
### Author:  [@Sam\_Austin](https://discourse.paraview.org/u/Sam_Austin)
#### Post date: [September 11, 2025, 8:54pm UTC](https://discourse.paraview.org/t/discontinuous-galerkin-support-in-paraview/16132/9 "2025-09-11T20:54:55Z")
Hi @dcthomp,
Awesome, thanks for those tips! I made those changes and can now load the file without warnings. Given our discussion above from February, I will stay tuned for updates to the Exodus/IOSS specification to support direct representation of lagrange coefficients in the Exodus format.