Is there an advantage/disadvantage/difference to using FEInterfaceValues (tutorial step 12) instead of the MeshWorker framework (tutorial step 12b) when it comes to DG?

[CopyCat]

Hello,

I am in the process of learning DG and dealii. 

I would like to implement a DG solver that would solve the convection-diffusion equation and later implement another code to solve the incompressible NS equation using DG as well. Tutorials 12 and 12b use different approaches to solve the pure convection equation, and so I was wondering which of these two approaches is better suited for my problem? 

Thanks 

[Wolfgang Bangerth]

> I would like to implement a DG solver that would solve the
> convection-diffusion equation and later implement another code to solve the
> incompressible NS equation using DG as well. Tutorials 12 and 12b use
> different approaches to solve the pure convection equation, and so I was
> wondering which of these two approaches is better suited for my problem?

The two approaches were developed for different purposes: FEInterfaceValues as
an approach to compute jump terms for DG methods in the same way as use
FEValues and FEFaceValues for evaluating the shape functions on cells and
faces. On the other hand, MeshWorker was meant as a framework that would make
the assembly of linear and bilinear forms over cells and interfaces easier. If
FEInterfaceValues had been around at the time MeshWorker was written, it would
have been one of the building blocks used there.

So there is no real equivalency between the two. The equivalence is more
between MeshWorker framework and the MeshWorker::mesh_loop() method used in
step-12 and step-47: As has been expressed many times on this mailing list,
MeshWorker has a good underlying idea, but it is not well documented or tested
and none of the people who frequently answer on the mailing list know it well.
In other words, its higher level functionality is in essence unmaintained. On
the other hand, MeshWorker::mesh_loop() *is* well documented and supported,
and has an interface that is relatively widely understood here. My preference
would have been to just remove step-12b when the previous version was
rewritten into what step-12 is now, rather than renaming it step-12b. (And do
the same for step-16b.) I consider step-12b and step-16b as obsolete.

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/