Feature Request: Support arbitrary Libxc hybrid functionals

[jeanwsr]

Describe the bug

This is a band job generated by AsterFire Go platform (ABACUS v3.10.1):

INPUT_PARAMETERS

...

# Electronic structure
basis_type          lcao
ks_solver           cusolver
dft_functional      HYB_GGA_XC_CAM_B3LYP
smearing_method     gauss
smearing_sigma      0.004
mixing_type         broyden
mixing_beta         0.4
mixing_ndim         20
mixing_gg0          1.0
gamma_only          0
scf_nmax            100
scf_thr             1e-07

...

In running_scf.log I found

 LCAO ALGORITHM --------------- ION=   1  ELEC=  14--------------------------------

 Density error is 6.11145223884e-08
----------------------------------------------------------
     Energy           Rydberg                 eV          
----------------------------------------------------------
 E_KohnSham     -21.1420813815       -287.6527743683      
 E_KS(sigma->0) -21.1420813815       -287.6527743683      
 E_Harris       -21.1420826434       -287.6527915366      
 E_band         -4.0734737497        -55.4224536500       
 E_one_elec     -157.0637584030      -2136.9620635763     
 E_Hartree      79.6573363944        1083.7936624667      
 E_xc           -5.6240622546        -76.5192925694       
 E_Ewald        61.8884028817        842.0349193107       
 E_entropy(-TS) -0.0000000000        -0.0000000000        
 E_descf        0.0000000000         0.0000000000         
 E_exx          0.0000000000         0.0000000000         
 E_Fermi        0.2450171022         3.3336286970         
----------------------------------------------------------

which seems incorrect since CAM-B3LYP is a RSH functional.

Expected behavior

CAM-B3LYP should have E_exx.

To Reproduce

No response

Environment

No response

Additional Context

No response

Task list for Issue attackers (only for developers)

• Verify the issue is not a duplicate.
• Describe the bug.
• Steps to reproduce.
• Expected behavior.
• Error message.
• Environment details.
• Additional context.
• Assign a priority level (low, medium, high, urgent).
• Assign the issue to a team member.
• Label the issue with relevant tags.
• Identify possible related issues.
• Create a unit test or automated test to reproduce the bug (if applicable).
• Fix the bug.
• Test the fix.
• Update documentation (if necessary).
• Close the issue and inform the reporter (if applicable).

[AsTonyshment]

Hi, to the best of my knowledge and based on my previous experience, ABACUS does not currently support arbitrary hybrid functionals simply by specifying their Libxc names. Hybrid functionals need to be explicitly supported by ABACUS itself; see https://abacus.deepmodeling.com/en/latest/advanced/input_files/input-main.html#dft-functional.

About a year and a half ago, I investigated this and implemented the BHLYP hybrid functional in my own fork. At that time, simply specifying a hybrid functional through Libxc was not sufficient to activate the corresponding exact-exchange calculation, and I believe the same limitation applies here.

[AsTonyshment]

@jeanwsr If CAM-B3LYP is urgently needed, we can consider adding explicit support for this functional. In the longer term, supporting arbitrary hybrid functionals through Libxc identifiers would certainly be valuable. However, this would likely require a substantial refactoring of the current XC module, so a general solution may not be available in the near future. 😭

[jeanwsr]

Thanks for the response. I think it's not hard to implement support for arbitrary Hyb/RSH libxc functional. For the type one can query XC_FLAGS_HYB_CAM, XC_FAMILY_HYB_*. For the coeff one can use xc_hyb_cam_coef. Although I know nothing about abacus development but these things are quite common in my developing experience of other programs that uses libxc.

[jeanwsr]

@jeanwsr If CAM-B3LYP is urgently needed, we can consider adding explicit support for this functional. In the longer term, supporting arbitrary hybrid functionals through Libxc identifiers would certainly be valuable. However, this would likely require a substantial refactoring of the current XC module, so a general solution may not be available in the near future. 😭

Thanks, that's not urgent. We can leave this issue open as a feature request.

[Growl1234]

In the longer term, supporting arbitrary hybrid functionals through Libxc identifiers would certainly be valuable.

Fully agreed. This will be more beneficial and robust, and I'd say please go ahead. Fortunately, ABACUS already has most of the underlying Libxc and EXX machinery needed for this, so I think the main work would be to generalize and unify the interface.

[Growl1234]

In the longer term, supporting arbitrary hybrid functionals through Libxc identifiers would certainly be valuable.

Fully agreed. This will be more beneficial and robust, and I'd say please go ahead. Fortunately, ABACUS already has most of the underlying Libxc and EXX machinery needed for this, so I think the main work would be to generalize and unify the interface.

To make the expected workflow easier and more controllable, we might want to discuss raising the minimum required version of Libxc to 7. Starting from Libxc 7.0, named external-parameter updates are persistent, so ABACUS could initialize a functional with Libxc defaults and then apply only explicitly requested named overrides, rather than reconstructing a complete parameter array for compatibility with older versions.

Btw Libxc is looking ahead to new major release (8.0.0), which will "feature a complete redesign of the API around a C++ core, together with support for new classes of functionals such as local hybrids and double hybrids", and remove autotools. I expect things to be much easier then :)

[AsTonyshment]

Agreed. I actually had this idea when I tried to test BHLYP through Libxc but found that ABACUS did not automatically enable the corresponding EXX contribution, so I had to implement explicit support for it myself. I considered generalizing this to arbitrary Libxc hybrid-functional identifiers at the time, but it was put aside because I was quite busy with paper-related testing.

Since I already have some experience from that implementation, and I also happen to be working on the EXX module for plane-wave RT-TDDFT recently, I may look into this in the near future. This could be a good opportunity to generalize and unify the current hybrid-functional interface.

[Growl1234]

In principle the expected workflow should also be applied to simpler functionals, such as r2SCAN etc. Could consider the "general" interface for simpler ones first, and I believe the goal specified here would be close enough.

[jeanwsr]

In the longer term, supporting arbitrary hybrid functionals through Libxc identifiers would certainly be valuable.

Fully agreed. This will be more beneficial and robust, and I'd say please go ahead. Fortunately, ABACUS already has most of the underlying Libxc and EXX machinery needed for this, so I think the main work would be to generalize and unify the interface.

To make the expected workflow easier and more controllable, we might want to discuss raising the minimum required version of Libxc to 7. Starting from Libxc 7.0, named external-parameter updates are persistent, so ABACUS could initialize a functional with Libxc defaults and then apply only explicitly requested named overrides, rather than reconstructing a complete parameter array for compatibility with older versions.

Btw Libxc is looking ahead to new major release (8.0.0), which will "feature a complete redesign of the API around a C++ core, together with support for new classes of functionals such as local hybrids and double hybrids", and remove autotools. I expect things to be much easier then :)

The "arbitrary functional" in this issue refers to any single functional without customized ext param I think, which is a basic functionality and don't need new libxc version. The ext param is an advanced functionality and maybe a little off-topic here.

Btw, I think xc_func_set_ext_params(_name) exists in 6.2, so I don't understand why 7.0 should be minimal.

[Growl1234]

Yeah, these are two separate topics. Supporting an arbitrary Libxc functional with its default parameters should not require Libxc 7, and the external-parameter redesign can be discussed separately.

My point about 7.0 was not that xc_func_set_ext_params_name() was introduced there, but that its semantics changed in 7.0: parameter values became persistent. In earlier versions, setting one named parameter resets the others to their defaults, while since 7.0 subsequent named overrides can be applied independently. That would make a metadata-driven named-parameter interface considerably simpler, but it is not a prerequisite for arbitrary functional selection.