I am trying to separate the whole code into problem definition, transport base and specific transport models.

The intension is that in the future if someone wants to add new transport feature, one can just simply add a new class derived from TransportBase class and provide cell, boundary and interface integration functions by overriding. Then it will be like in MOOSE.

The code part for high-order system.

Current material ID input is not convenient as inputing such information is performed "row-by-row" fixing y and z values. I am thinking about introducing a parameter reading material ID file name and then ProblemDefinition directly read that file for material IDs.

After this issue, we will focus on physical iterative solvers: iterations and accelerations.

Intension is s.t. after we take out this one and angular quadrature, we don't need to template ProblemDefinition on dim, so we can intake dimension from input file and construct TransportBase based on intaken dim.

Up to now, I think I got all the main body of the code. So the task now is to debug the code and make it run.

Things that are not done but will be done in the future:

1. Modularly testing.
2. Figure out how to make git test on the fly when merging.
3. Documentation through Doxygen.

After this isolation, we will be able to de-template ProblemDefinition so that user can take dimension as an input parameter.

Also, user can actually derive new angular quad if needed from the base.

The intention is to gradually make efforts on isolating TransportBase's functionality. It should not contain functionality of making grids directly, which is supposed to be taken care of by other classes.

This is a continuation from last PR. Tasks are:

1. Fix the asymmetry issue when doing symmetric tests: find the bug
2. Work with deal.II team to figure out what's going on with MPI.