LR-TDDFT Implementation

[maki49]

What's this issue for?

• updating new developments
• asking questions
• being linked when modifying the existing code for the new feature

Problem 1: How can we get ground state infomation from ESolver_KS for beyond DFT methods?

The ground state information means wavefunction psi::Psi and band energy pelec->ekb.
Of course, we can write a file that will be read in the excited-state solver. But I think there should be a more elegant way like this:

// in Driver::driver_run():
psi::Psi ks_psi = p_esolver->get_psi();
ESolver_LRTDDFT(ks_psi);

However, this is not supported in the current program framework using polymorphism, because Psi is in the derived class and a pointer to the base class cannot get it.

Also, I don't think it's a reasonable way to let ESolver_LRTDDFT be a child class of ESolver_KS (from both code structure and physics points of view).

Are there any better solutions other than write-and-read or putting Psi into the base class ESolver?

[maki49]

The idea I want to try: to implement a move constructor: ESolver_LRTD(ESolver_KS_LCAO&&), std::move the following things:

• ground state infomation
  • psi, psid
  • pelec->ekb
• something with no difference between two ESolvers (to avoid copy and reintialization)
  • LCAO_Orbitals GlobalC::ORB
  • Gint_gamma GG
  • Grid_Technique GlobalC::GridT
  • ...

Now I think this way is feasible. It has been succeeded for Psi and ekb //ModuleBase::matrix, but for the other classes I need to implement in each one a T& operator=(T&&) with pointer operation.

---

Polymorphism is not a promlem, because dynamic_cast can convert a base class pointer to a pointer to its child class.

[maki49]

Problem 2: Parallel Distribution of X-vectors (nc * nv * nstates)

• The size of X-vectors is npairs * nstates, where npairs = nc * nv is the "nbasis" of 2-particle eigenstates and nstates is the number ("nbands") of 2-particle eigenstates to be solved.

• The class psi::Psi will be used to store the X-vector.

Maybe just like the ParaV for KS wavefunction in LCAO, but which dimention to distribute?

• dividing npairs into each row-block and nstates into each col-block?
• or dividing nocc into each row-block and nvirtual into each col-block?
• or just like PW, only dividing basis(npairs) while not dividing bands(nstates) ?

---

Problem 3: How to set the initial guess of X ?

• I have no idea now, maybe @ouqi0711 or @jinzx10 can help.

Solution: use unit vectors (set the pairs most close to homo-lumo to 1).
A diagonal-arranged X-index will be implemented: the closer to homo-lumo for a e-h pair, a smaller index it will have.

---

Problem 4: Should we move the interfaces hPsi and act from OperatorPW to the base class Operator?

• hPsi and act are needed in the kernels of the Casida equation, and they should be supported in KS-LCAO too (in the future).

[jinzx10]

Problem 3: How to set the initial guess of X ?

• I have no idea now, maybe @ouqi0711 or @jinzx10 can help.
  If you are asking the initial guess for Davidson diagonalization, I guess one viable option is to use a set of unit vectors that correspond to the smallest diagonal elements of A matrix.

[maki49]

5: Parallel of transition density matrix before grid intergral

There's nothing special in the grid integral calculation: just to call Gint::cal_gint with job rho and vlocal successively.

However, calculation of the transition density matrix $ \tilde{\rho}{\mu\nu} = \sum{jb} c_{j,\mu} X_{jb} c^*_{b,\nu} $
(grid parallelized, with the size of density matrix of ground state: lgd*lgd) before doing grid intergral will be the biggest difficulty.

I may need to refer to the function cal_dk_gamma_from_2D and cal_dk_k.

(If parallel distribution of X is considered, things will be more difficult...)

[hongriTianqi]

• Review and understand the proposed feature and its importance.
• Research on the existing solutions and relevant research articles/resources.
• Discuss with the team to evaluate the feasibility of implementing the feature.
• Create a design document outlining the proposed solution and implementation details.
• Get feedback from the team on the design document.
• Develop the feature following the agreed design.
• Write unit tests and integration tests for the feature.
• Update the documentation to include the new feature.
• Perform code review and address any issues.
• Merge the feature into the main branch.
• Monitor for any issues or bugs reported by users after the feature is released.
• Address any issues or bugs reported by users and continuously improve the feature.

[hongriTianqi]

@maki49 It might help to manage related PR and issues using a project : LR-TDDFT Implementation

[mohanchen]

This has been done. Great job!