You’ve been busy 
this looks promising.
Before I actually dive into the implementation details, a couple of pragmatic questions come to mind:
- I see that the code is added into the existing VTK modules (e.g., Common/DataModel). I would consider having compile-time flags to enable/disable inclusion of these DG classes, and/or segregate them into their own module(s). (We spent a fair amount of time modularizing VTK etc. - VTK continues to grow in size and it is very important that users can enable/disable code that they want/don’t want.)
- It would be nice to see a few more algorithms implemented, for example isocontouring, probing, and/or streamlines (did I miss these in your MR?). It would help the community understand the practical usage of these classes. So a suggestion for addressing missing features: identify 4-5 important algorithms and then implement them (at a very rudimentary level), extending/adjusting APIs as necessary.