北京大学陈默涵课题组用户2166
Introduction to ABACUS: Path to PW calculation - Summary Final
输入“/”快速插入内容
Introduction to ABACUS: Path to PW calculation - Summary Final
Introduction to ABACUS: Path to PW calculation - Summary Final
📃写在前面
1.
不脱离代码——避免读者看完手册后对代码没有一丁点概念
2.
不堆砌代码解释——避免平庸的代码解释，努力兼顾拉近读者和代码距离的同时，做到提纲挈领，不逐行复制代码后进行停留在代码语义上的解释
Flow：ABACUS里的工作流
回忆我们的起点，从main()函数出发，经过MPI初始化后到达Driver，然后到Driver_run()。是Driver_run()唤起了整个程序的实际运行部分，其实迄今为止我们所看到的所有“故事”，都发生在Driver_run()的ESolver::init()，以及Relax_Driver::run()。
我们同样也拥有更低层级的driver，比如ESolver_KS::Run()函数，实际上ESolver的Run()函数只关心SCF，即只关心“求得能量”，尽管有另一个相似命名的模块，HSolver，其关注的范围其实更小：只关注Hamiltonian矩阵的对角化。
因此我们可以画出一个分层级的workflow，在不同workflow上引导的则是driver：
另有Run_md和Relax_Driver是平行关系，但由于我们目前仍未正式涉及MD的相关代码，因此不在上图中画出。
Interface：串联模块的组织模式
Inteface设计的必要性
遗憾的是，GlobalV和GlobalC虽然提供了“参数上云、用时下载”这一概念并方便了对待模拟体系的描述相关参数传递和热点函数调用，但对于单元测试来讲却并非好的设计，尤其对于GlobalC。我们可能在编写单元测试（以确定模块功能正常运作）时，会遇到对过多变量进行初始化的问题，例如我们只想使用UnitCell GlobalC::ucell，include GlobalC的头文件后，却发现了诸多的“undefined reference to Parallel_Kpoints”等问题。
从设计上来讲，这是发生了类间耦合，尽管这种耦合可能在设计之初未被预计到。因此为了能够尽可能大地减少基于GlobalC的类间耦合，更加提倡不使用GlobalC，而是从具体的某个类被定义的地方设计接口（指针进行调用），如对于一个类illustrate_interface的函数illustrative_f，我们如果需要使用UnitCell GlobalC::ucell，不写成：
代码块
void illustrate_interface::illustrative_f()
{
....
std::cout << "The address of ucell: " << &(GlobalC::ucell) << std::endl;
....
}
而是在illustrate_interface类中创建一个interface：
代码块
class illustrate_interface
{
private:
UnitCell* p_ucell;
};
该interface可以在构造函数中被指定，也可以使用相应setter函数。之后对illustrative_f函数的编写就成为：
代码块
void illustrate_interface::illustrative_f()
{
....
std::cout << "The address of ucell: " << this->p_ucell << std::endl;
....
}
如此一来使得实际所使用的GlobalC中类（比如UnitCell）和其他类解耦开。
（单元测试）尽情mock你想要使用的类
假设你想要在单元测试中使用一些函数，但你include实现那个函数的cpp文件后发现出现了很多棘手的undefined reference to xxx，应该怎么办？又或者在你include的类中有其他的类对象作为成员，然后编译器提示报错undefined reference to [class]::[class]()，怎么办？
除了可以尝试使用gmock这个googletest提供的函数框架外，第二种思路只需要记住一件事：因为你只include了头文件，所以你可以实现当中的任何函数，而非必须包含进来它原本的实现（即所对应的原本的cpp文件）。