Repository navigation
Feature Request: Support arbitrary Libxc hybrid functionals #7787
Description
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).
Activity
AsTonyshment commentedon Aug 8, 2026
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 commentedon Aug 8, 2026
@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 commentedon Aug 8, 2026
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 usexc_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 commentedon Aug 8, 2026
Thanks, that's not urgent. We can leave this issue open as a feature request.
Growl1234 commentedon Aug 8, 2026
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 commentedon Aug 8, 2026
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 commentedon Aug 8, 2026
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.
[-]CAM-B3LYP calculation via libxc has no exx[/-][+]Feature Request: Support arbitrary Libxc hybrid functionals[/+]Growl1234 commentedon Aug 8, 2026
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 commentedon Aug 8, 2026
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 commentedon Aug 8, 2026
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.jeanwsr commentedon Aug 8, 2026
Oh that makes sense.
QuantumMisaka commentedon Aug 27, 2026
Additional reproduction and terminal test results (2026-08-27), using the current SAI-native production runtime:
Runtime baseline
abacus/LTSv3.10.1-sm70-autoEXX=true;LibRI=true;basis_type=lcaoMinimal input
The control cases use the same fixture and runtime, changing only
dft_functionalwhere applicable.Observed results
alpha=.20, EXX reruns,Exx_LRIpresentHYB_GGA_XC_CAM_B3LYPE_exx=0; noExx_LRIor EXX outer loopHYB_GGA_XC_BHANDHLYPalpha=.50recorded, but terminalE_exx=0; noExx_LRIor EXX outer loopThis separates dependency/build availability from functional semantics: the same runtime executes native B3LYP EXX successfully, while generic Libxc Hybrids follow only the semilocal SCF path.
Requested regression gate after a fix
E_exx, EXX outer loop/Exx_LRI, and correct range-separation parameters.The current results indicate a reproducible ABACUS generic-Hybrid runtime dispatch gap, not a missing SIF dependency or a Toolbox input issue. Parser acceptance and static Libxc/LibRI build facts should not be treated as runtime support evidence.