基本上，与求解器无关的上层类都设计得差不多了，然后就是求解器这个部分要开始做了。求解器部分的设计不是那么容易，所以还是先看看其它开放源代码的结构吧。
首先我再次看了一下Overture的模式。在Overture的一般算例中，并没有特别提供求解器这一个部分，而是用户自己在程序中创建某种形状的映射网格MappedGrid、与网格匹配变量数组GridFunction，再根据方程的离散形式来调用Operator对GridFunction进行某些差分操作来完成计算，并控制中间输出显示。因此，Overture一般模式里面，用户程序本身就是一个求解控制器，隐含的利用Overture的操作来实现FDM或者FVM的求解器。
而在Overture同时提供的一个专门CFD求解器OverBlown中，却实现了一个很庞大的玩意——包括图形界面、输入输出、泊松方程/不可压NS方程/可压NS方程/全速度NS方程多个求解器，而且提供网格自适应、运动网格、各种时间离散格式……。OverBlown的主程序十分简短，
=====================================================================
.........
cout << "Running OverBlown...\n";
Overture::start(argc,argv); // initialize Overture
.........
// create and read in a CompositeGrid
CompositeGrid m;
getFromADataBase(m,nameOfOGFile);
CompositeGrid & cg = m.numberOfMultigridLevels()==1 ? m : m.multigridLevel[0];
if( m.numberOfMultigridLevels() > 1 )
m.update(CompositeGrid::THEmultigridLevel);
Interpolant interpolant(cg);
interpolant.setImplicitInterpolationMethod(Interpolant::iterateToInterpolate);
Ogshow *show=NULL;
OverBlown solver(cg,&ps,show,plotOption);
solver.setParametersInteractively();
solver.solve();
solver.printStatistics();
.........
=====================================================================
关键就是最后几行，创建一个OverBlown对象，设置好参数后求解。然而查看OverBlown类的代码，就会发现OverBlown类并不具体涉及求解过程控制和求解计算，而只是配置参数，组合网格对象、OB_CompositeGridSolver对象，solver方法只是调用计算OB_CompositeGridSolver的advance方法。因此OverBlown类实际扮演的角色时一个Case管理类（就相当于我这里的Case类了）。
OB_CompositeGridSolver类十分大，涉及到具体的方程的类型、自适应、运动网格、时间离散格式……。不过OB_CompositeGridSolver类仍然没有执行具体最具体的数值求解，而是把这个任务交给每个子网格各自的求解器OB_MappedGridSolver来完成。OB_MappedGridSolver类的核心方法就是getUtX，既采用各种不同方法来计算求解变量的变化。因此，大概可以说OB_CompositeGridSolver类是负责组合网格求解的，而OB_MappedGridSolver类才是一个基本针对单块网格的求解器。
在AMROC中，是SolverControl-Solver结构。如下图
SolverControl结构
可以看到SolverControl类包含一个网格GridHierarchy、一个Solver，以及其它部件，同时SolverControl类和Solver类都通过ControlDevice支持外部参数控制。SolverControl类的关键方法是Solve，它完成创建网格、声明求解变量数组、初始化文件读取、存储间隔管理，最关键的一步就是调用自己的Solver对象的Tick方法将流场向前推进一个指定的时间步长。
Solver结构
Solver结构要复杂得多，包含边界条件、初始条件、求解变量、单步积分器……，它才是实现求解的类。不过Solver类本身并没有实现上述关键的方法Tick，而是由其子类来实现的。
AMRSolver
AMRSolver是针对AMR网格的一个求解器，因此它的关键方法Tick实现了AMR算法的一步推进。同时AMRSolver其实也衍生由一些变体，不过基本都差不多。不过再往伸出追究，就会发现AMRSolver虽然实现了一个网格树上的AMR算法，但是单块网格的一步推进实际上是由单步积分器Integrator类完成的，而Integartor类封装了一套Fortran 77代码。
再回头看OverBlown的结构，倒不如AMROC清晰分明，它的没有一个和具体Solver无关的SolverControl，使得OB_CompositeGridSolver类承担了SolverControl和Solver的双重功能。
我无法得到别的C++ CFD代码，所以没法再从源代码级做更广泛的调查了。不过在商业CFD软件中，同样也可以看到这种类似Case/SolverControl-Solver结构。主程序读取网格，用户通过菜单和对话框设置初边条件、计算模型、求解器、结果输出等等，构造成一个case文件。不过Case-SolverControl经常是合并的。我当初为什么加入一个Case层次呢？干脆也合并吧。
