- Discontinuous Galerkin implementation with arbitrary choice of (polynomial) shape functions
- arbitrary order
- p-refinement over macro-elements
- matrix-free operator evaluation
- weak form generation via HFG
- evaluation of functions and linear functionals for right-hand side assembly generated via HFG
- direct volume to volume communication (interface primitives not used)
- SIP for Poisson
- hp-multigrid (maybe also projection into continuous element space?)
- weakly imposed boundary conditions
- upwind operator
- Volume DoF data structure + DGFunction class w/ basic indexing functionality
- DGOperator class, apply, toMatrix()
- mass form, interpolation
- linear form for RHS
- Laplace form (SIP, interface integrals)
- communication (PackInfo etc.), macro-interface integrals
- inhom. Dirichlet BCs.
- higher order shape functions
- HFG refactoring and fixed DGForm API
- 3D extensions
Possible optimizations / open refactoring / dev notes
optimize evaluation by precomputing and storing trafo matrices on each macro-face / macro-cell (it's recomputed every time in the evaluation function)
make all methods in DGBasisInfo const
give DGForms the following virtual methods
isConstant(): true if the form is constant over the macro - so optimization can be applied
isInlined(): true if entire kernel is available
onlyInnerIntegrals(): true if only volume integrals are non-zero (think mass matrix) - this allows to implement efficient(?) local inversion of the block-diagonal system without communication
probably we should not double the information about the local polynomial degree in each macro in the DGFunction AND VolumeDoFFunction
optimize VTK evaluation by new DGFunction::evaluate( faceID, microIdx, faceType, ... ) method that skips looking for the micro-element - we know already which one we are targeting (this is not only an optimization but also fixes slightly incorrect visualization)
what to do with the DoFType 'flags'?
implement affine element-local evaluation directly in HFG
Optimize HFG trafo matrix computations by letting it know which element vertices belong to the interface. This should allow for some cancellations since some of the input points are actually equal.
There is an issue if the boundary macros are marked as 'Inner' as done for Stokes usually - since then the DGOperator 'thinks' that there must be another volume macro on the other side. Boom.
Instead of resizing the element matrices, the HFG should rather assert that the size is already correct.