Question: remove the check on `dft_functional` attribute in pseudopotentials?

[kirk0830]

Background

For some pseudopotentials, the PBE functional will be written as "SLA-PW-PBX-PBC" instead of simply PBE.
The pseudopotential converted from CP2K will have value "DFT" for this attribute.

Describe the solution you'd like

I doubt that the check on dft_functional attribute of pseudopotential is not necessary, user should take his/her own responsibility to use pseudopotentials.

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.

[sunliang98]

Thank you for raising this point. In my opinion, it is indeed crucial to validate the dft_functional attribute associated with pseudopotentials. If a user employs a pseudopotential developed under the LDA framework while specifying the dft_functional as PBE, it can lead to inconsistencies and potentially render the simulation results unreliable or physically meaningless. Therefore, we believe that maintaining a check on the compatibility between the pseudopotential and the specified DFT functional is beneficial as a safeguard against such issues.
However, if a user confirms that their choice is appropriate, they can safely ignore the warning.

[kirk0830]

@sunliang98 is it merely a warning now? As far as I remember, if there is a mismatch between pseudopotential and the dft_functional, then the warning_quit will be triggered. I understand your meaning, but in practice it is more complicated than the case you describe because I have experience in utilizing different functionals in practical calculation. There may be at least three tricky cases you missed:

1. a GGA functional that has no available pseudopotential: this is the case of BLYP, PW91/2, BEEF-vdw (but vdw-DF is not supported by ABACUS yet), so on.
2. all meta-GGA functional. In early versions, there are no direct pseudopotential support of SCAN in CP2K. In those days, people use pseudopotentials of PBE for SCAN.
3. all hybrid functional. Almost in all periodic DFT implementations, the pseudopotential used for hybrid functionals are those actually of GGA or LDA.

Regards.

[sunliang98]

@sunliang98 is it merely a warning now? As far as I remember, if there is a mismatch between pseudopotential and the dft_functional, then the warning_quit will be triggered. I understand your meaning, but in practice it is more complicated than the case you describe because I have experience in utilizing different functionals in practical calculation. There may be at least three tricky cases you missed:

1. a GGA functional that has no available pseudopotential: this is the case of BLYP, PW91/2, BEEF-vdw (but vdw-DF is not supported by ABACUS yet), so on.
2. all meta-GGA functional. In early versions, there are no direct pseudopotential support of SCAN in CP2K. In those days, people use pseudopotentials of PBE for SCAN.
3. all hybrid functional. Almost in all periodic DFT implementations, the pseudopotential used for hybrid functionals are those actually of GGA or LDA.

Regards.

Thank you for your detailed feedback and examples.

Currently, it triggers a warning rather than a hard stop:
dft_functional readin is: lda
dft_functional in pseudopot file is: PBE
Please make sure this is what you need.

This warning aims to alert users to potential inconsistencies that could affect their results. For the more complex cases you've outlined—such as using GGA, meta-GGA, or hybrid functionals—if users are confident in their choices, they can safely ignore the warning, and ABACUS will produce the expected results.

Therefore, I believe retaining this check is necessary. It does not prevent users from handling more complex cases but serves to avoid potential mistakes by users.

[kirk0830]

@sunliang98 Hi, could you check why this does not work? The functional name in pseudopotential is under the Quantum ESPRESSO convention: SLA-PW-PBX-PBC, which is, Slater exchange, PW LDA correlation, PBE exchange, PBE correlation:
SLA-PW-PBX-PBC.zip

[sunliang98]

This case dose not work for two reasons:

1. The functional name SLA-PW-PBX-PBC (which represents PBE) is not recognized by ABACUS or Libxc directly, leading to the error message: functional name not recognized!.
2. The PP_RHOATOM section of the pseudopotential file contains all zeros. This causes an assertion failure (Assertion charge != 0.0 || charge == atom->ncpp.zv failed.) even if we set dft_functional pbe in the INPUT file.

In QE, the names like SLA-PW-PBX-PBC are internally converted to corresponding indices via the set_dft_from_name function in Modules/funct.f90, as shown in the attached image:

To resolve this issue and support this pseudopotential, consider the following options:

1. Simply specify dft_functional pbe in INPUT;
2. Update the functional name within the pseudopotential file to a recognized format.;
3. Modify ABACUS to recognize the complete functional names used in the pseudopotential files.

[kirk0830]

@sunliang98 ouch, I have not noticed the RHOATOM is all-zero. I think a warning_quit with more details like "one should explicitly specify the dft_functional parameter in this case" in needed, and then a further support on the notation "SLA-PW-PBX-PBC" can be implemented in the future. For the former, I will submit PR to do that very soon.