Feature: change criterion in kerker dielectric matrix calculations for charge mixing

[WHUweiqingzhou]

Background

Now ABACUS realize a kerker preconditioner in Charge_Mixing::Kerker_screen_real() & Charge_Mixing::Kerker_screen_recip(). This preconditioner is a simple diagonal model for the inverse of the dielectric matrix in metallic systems, and can effectively suppress the oscillations in the low-q components of the charge density:
$$G_q^1=\frac{q^2}{q^2+q_0^2}$$
Current implementation is:
double filter_g = std::max(gg / (gg + gg0), 0.1);
which mean low-q (gg / (gg + gg0)->0) contributions is always with a minimum weight of 0.1, and once gg / (gg + gg0)>0.1, corresponding weight would increase as q-vector. This implementation is not agreement with VASP:
G0(K)=MAX(AMIX*GSQU/(GSQU+FLAM),AMIN)
We can see VASP use AMIN = 0.1 as default, but compare it with $A\frac{q^2}{q^2+q_0^2}$. ABACUS also use 0.1 as default and compare it with $\frac{q^2}{q^2+q_0^2}$ directly. For some systems hard to converge, mixing_beta $A$ will be very small. In this case, current minimum kerker matrix is much smaller than the one of VASP.
My suggestion is realized kerker in this way
double filter_g = std::max(gg / (gg + gg0), A1/this->mixing_beta);
here, A1 is a variable with a default value 0.1. In this way, we do not need to change current design of module_mix, and can get same kerker matrix as VASP
(https://www.vasp.at/wiki/index.php/IMIX#cite_note-kerker:prb:81-1).

Describe the solution you'd like

realize
double filter_g = std::max(gg / (gg + gg0), A1/this->mixing_beta);
in Charge_Mixing::Kerker_screen_real() & Charge_Mixing::Kerker_screen_recip().
I will fix it.

Task list only for developers

• Notice possible changes of behavior
• Explain the changes of codes in core modules of ESolver, HSolver, ElecState, Hamilt, Operator or Psi

Notice Possible Changes of Behavior (Reminder only for developers)

No response

Notice any changes of core modules (Reminder only for developers)

No response

Notice Possible Changes of Core Modules (Reminder only for developers)

No response

Additional Context

No response

Task list for Issue attackers (only for developers)

• 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.