Feature: LR-TDDFT support reading fxc from file or calculating fxc by a specified charge file

[maki49]

See the documentation of parameter init_fxc.

[kirk0830]

I have reviewed this PR, and this is the first time that I dive (somehow) into the module_lr code, so I submit several comments on details in files changed, no matter whether they are changes made in this PR.
This PR supports a new functionality that restarting the LR calculation from file that can be provided by user. However, in the view of program design, there are indeed several problems needed to solve in the future.

1. file structure is not organized well. In module_lr there is a file named esolver_lrtd_lcao, and all other files whose names startwith esolver are in folder module_esolver. I cannot tell immediately which is a better way but at least the inconsistency is obvious. In module_lr there are folders named operator_casida, potentials, and utils. However, in folder operator_casida, there is a file named operator_lr_hxc.cpp, it appears like there is a folder named fruit_apple and in it there is a file named plant. There are also files whose names contain lr, others contain lrtd, so I am confused what is the relationship between the lr and lrtd. I also note there is a a file named lr_util.h and then another lr_util.hpp, this is quite confusing, because .h usually indicates header file of C, and .hpp for C++, especially when they appear at the same time. Then there are files named lr_util and then lr_util_xc, there seems to be strong naming overlap: module_lr/utils/lr_util.*.
2. There is inconsistency in the newly added keyword lr_init_xc_kernel. The linear-response is abbreviated as lr, initialize as init, exchange-correlation as xc but no abbr for kernel.
3. There is dependency on Global variables such as GlobalC::Pgrid. The problem is other developers cannot realize immediately how to change the behavior of function which is the caller of function where the GlobalC::Pgrid is used as parameter, and if it appears in a class's member function, it is obviously a not good encapsulation.
4. The instantiation of class PotHxcLR has explicit dependency on rank number, this design is not clearly explained.
5. KernelXC class is used as a place to store data, all its important data members are public. It is explained that because there will be too many getter functions, so no getter function is written.
6. The instance of class PotHxcLR will change the global static value XC_Functional::func_id. It is explained that because the module_lr is always the last one called in the whole ABACUS workflow, so this operation should be acceptable. Personally I really doubt about this but seems this is true at present.

[mohanchen]

I have reviewed this PR, and this is the first time that I dive (somehow) into the module_lr code, so I submit several comments on details in files changed, no matter whether they are changes made in this PR. This PR supports a new functionality that restarting the LR calculation from file that can be provided by user. However, in the view of program design, there are indeed several problems needed to solve in the future.

1. file structure is not organized well. In module_lr there is a file named esolver_lrtd_lcao, and all other files whose names startwith esolver are in folder module_esolver. I cannot tell immediately which is a better way but at least the inconsistency is obvious. In module_lr there are folders named operator_casida, potentials, and utils. However, in folder operator_casida, there is a file named operator_lr_hxc.cpp, it appears like there is a folder named fruit_apple and in it there is a file named plant. There are also files whose names contain lr, others contain lrtd, so I am confused what is the relationship between the lr and lrtd. I also note there is a a file named lr_util.h and then another lr_util.hpp, this is quite confusing, because .h usually indicates header file of C, and .hpp for C++, especially when they appear at the same time. Then there are files named lr_util and then lr_util_xc, there seems to be strong naming overlap: module_lr/utils/lr_util.*.
2. There is inconsistency in the newly added keyword lr_init_xc_kernel. The linear-response is abbreviated as lr, initialize as init, exchange-correlation as xc but no abbr for kernel.
3. There is dependency on Global variables such as GlobalC::Pgrid. The problem is other developers cannot realize immediately how to change the behavior of function which is the caller of function where the GlobalC::Pgrid is used as parameter, and if it appears in a class's member function, it is obviously a not good encapsulation.
4. The instantiation of class PotHxcLR has explicit dependency on rank number, this design is not clearly explained.
5. KernelXC class is used as a place to store data, all its important data members are public. It is explained that because there will be too many getter functions, so no getter function is written.
6. The instance of class PotHxcLR will change the global static value XC_Functional::func_id. It is explained that because the module_lr is always the last one called in the whole ABACUS workflow, so this operation should be acceptable. Personally I really doubt about this but seems this is true at present.

@maki49 I suggest you answering to someone who spent a lot of time reviewing your codes in an appropriate way, even if you don't want to follow his suggestions.

[maki49]

@kirk0830 Thanks for spending time to review. For point 5, the public members are all const references being used like getters, as what PARAM.inp does. Other points is something to be changed or discussed in another PR.

@mohanchen I have already changed all the things related to the feature implemented in this PR following his suggestion.