search

deepmodeling / abacus-develop

An electronic structure package based on either plane wave basis or numerical atomic orbitals.
http://abacus.ustc.edu.cn
GNU Lesser General Public License v3.0
176 stars 136 forks source link

variables "dft_functional" and "exx_hybrid_alpha" in using HSE hybrid functional #2945

Closed Luc1anoo closed 11 months ago

Luc1anoo commented 1 year ago

Describe the bug

I encountered some problems when using INPUT variable "dft_functional" and "exx_hybrid_alpha". The questions are as follow:

  1. Is there a difference between using uppercase and lowercase in variable "dft_functional" and which one should be chosen? For example: dft_functional == hse vs dft_functional == HSE I noticed that the format "hse" has been chosen in the introduction (https://abacus.deepmodeling.com/en/latest/advanced/input_files/input-main.html#dft-functional) and in most examples, such as https://nb.bohrium.dp.tech/detail/8041860882. But when I used "hse" in scf calculation, the processing was stopping at "Initial plane wave basis and FFT box"and then terminated.

    Use Systematically Improvable Atomic bases

    ELEMENT ORBITALS NBASE NATOM XC
    Ge 2s2p2d-8au 18 63
    C 2s2p1d-8au 13 1

    Initial plane wave basis and FFT box

    ================================================================================== = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES = RANK 0 PID 685 RUNNING AT bohrium-17819-1028724 = KILLED BY SIGNAL: 9 (Killed)

    ...

By contrast, the scf calculation will run successfully when I set "dft_functional == HSE". I checked the "source code" later and it seems like the format "HSE" is the correct option:

ifdef USE_LIBXC

else if( xc_func == "HSE")
{
    func_id.push_back(XC_HYB_GGA_XC_HSE06);
    func_type = 4;
    use_libxc = true;
}

2.The variable "exx_hybrid_alpha" doesn't seem to work. I changed the variable from default 0.25 to 0.18 in INPUT file running scf calculation and keep all other variables unchanged. Finally, I got two band diagrams which are exactly the same after running nscf calculation. I also have done the comparison in systems with different atoms(16, 64, 128) and the 16 atoms system got two same band diagrams, so did the 64 and 128 atoms system.There aren't examples about this variable so I wonder whether I used this variable incorrectly?

Expected behavior

No response

To Reproduce

No response

Environment

No response

Additional Context

files for scf calculation:

INPUT: INPUT_PARAMETERS

suffix GeC16 pseudo_dir /data/abacus-develop/tests/PP_ORB orbital_dir /data/abacus-develop/tests/PP_ORB ntype 2 calculation scf init_chg atomic dft_functional HSE exx_hybrid_alpha 0.18 ecutwfc 50 nspin 1 gamma_only 0 scf_nmax 300 scf_thr 1e-7 basis_type lcao ks_solver genelpa out_chg 1 out_level ie out_mat_hs2 1 out_mat_r 1

KPT: K_POINTS 0 Gamma 1 1 1 0 0 0

STRU: ATOMIC_SPECIES Ge 72.63 Ge_ONCV_PBE-1.0.upf upf201 C 12.011 C_ONCV_PBE-1.0.upf upf201

NUMERICAL_ORBITAL Ge_gga_8au_100Ry_2s2p2d.orb C_gga_8au_100Ry_2s2p1d.orb

LATTICE_CONSTANT 1.8897259886

LATTICE_VECTORS 11.3149995804 0 0 #latvec1 0 5.6574997902 0 #latvec2 0 0 5.6574997902 #latvec3

ATOMIC_POSITIONS Direct

Ge #label 0 #magnetism 15 #number of atoms 0 0 4.15042712575e-31 m 1 1 1 0 0.5 0.5 m 1 1 1 0.268128004664 0 0.5 m 1 1 1 0.268128004664 0.5 0 m 1 1 1 0.403234643615 0.279235673252 0.720764326748 m 1 1 1 0.135060943246 0.244890775692 0.244890775692 m 1 1 1 0.135060943246 0.755109224308 0.755109224308 m 1 1 1 0.403234643615 0.720764326748 0.279235673252 m 1 1 1 0.5 0 0 m 1 1 1 0.731871995336 0 0.5 m 1 1 1 0.731871995336 0.5 0 m 1 1 1 0.864939056754 0.244890775692 0.755109224308 m 1 1 1 0.596765356385 0.279235673252 0.279235673252 m 1 1 1 0.596765356385 0.720764326748 0.720764326748 m 1 1 1 0.864939056754 0.755109224308 0.244890775692 m 1 1 1

C #label 0 #magnetism 1 #number of atoms 0.5 0.5 0.5 m 1 1 1

files for bandstructure calculation

Input: INPUT_PARAMETERS {

nspin                           1   
package                         ABACUS
fermi_energy                    12.846682707
fermi_energy_unit               eV  
HR_route                        data-HR-sparse_SPIN0.csr
SR_route                        data-SR-sparse_SPIN0.csr
rR_route                        data-rR-sparse.csr
HR_unit                         Ry  
rR_unit                         Bohr

}

LATTICE { lattice_constant 1.8897162 lattice_constant_unit Bohr lattice_vector 11.3149995804 0 0 #latvec1 0 5.6574997902 0 #latvec2 0 0 5.6574997902 #latvec3 }

BAND_STRUCTURE { wf_collect 0 kpoint_mode line kpoint_num 5 high_symmetry_kpoint
0.50000 0.50000 0.5000 50 # L 0.00000 0.00000 0.0000 50 # G 0.50000 0.00000 0.5000 50 # X 0.37500 -0.37500 0.0000 50 # K 0.00000 0.00000 0.0000 1 # G }

BANDUNFOLDING { stru_file STRU ecut 100 band_range 1 130 m_matrix -2 2 2 1 -1 1 1 1 -1 kpoint_mode line kpoint_num 5 high_symmetry_kpoint 0.50000 0.50000 0.5000 50 # L 0.00000 0.00000 0.0000 50 # G 0.50000 0.00000 0.5000 50 # X 0.37500 -0.37500 0.0000 50 # K 0.00000 0.00000 0.0000 1 # G }

STRU: ATOMIC_SPECIES Ge 72.63 Ge_ONCV_PBE-1.0.upf upf201 C 12.011 C_ONCV_PBE-1.0.upf upf201

NUMERICAL_ORBITAL Ge_gga_8au_100Ry_2s2p2d.orb C_gga_8au_100Ry_2s2p1d.orb

LATTICE_CONSTANT 1.8897259886

LATTICE_VECTORS 11.3149995804 0 0 #latvec1 0 5.6574997902 0 #latvec2 0 0 5.6574997902 #latvec3

ATOMIC_POSITIONS Direct

Ge #label 0 #magnetism 15 #number of atoms 0 0 6.35259418151e-31 m 1 1 1 0 0.5 0.5 m 1 1 1 0.266885600211 0 0.5 m 1 1 1 0.266885600211 0.5 0 m 1 1 1 0.402220887542 0.279452468331 0.720547531669 m 1 1 1 0.134316944248 0.245265950302 0.245265950302 m 1 1 1 0.134316944248 0.754734049698 0.754734049698 m 1 1 1 0.402220887542 0.720547531669 0.279452468331 m 1 1 1 0.5 0 0 m 1 1 1 0.733114399789 0 0.5 m 1 1 1 0.733114399789 0.5 0 m 1 1 1 0.865683055752 0.245265950302 0.754734049698 m 1 1 1 0.597779112458 0.279452468331 0.279452468331 m 1 1 1 0.597779112458 0.720547531669 0.720547531669 m 1 1 1 0.865683055752 0.754734049698 0.245265950302 m 1 1 1

C #label 0 #magnetism 1 #number of atoms 0.5 0.5 0.5 m 1 1 1

Task list for Issue attackers

hongriTianqi commented 1 year ago

@Luc1anoo Thanks for your report. ABACUS will change input of dft_functional to upper case, so the error you met is abnormal. Could you please attach all the inputs for this case for us to repeat to error. Thanks.

xdzhu commented 1 year ago

Recently I also met the similar problem. However, I want to tell you the fact is that "dft_functional hse" is the right case rather than the uppercase. The error message actually comes from the lack of memory so that it exits with "KILLED BY SIGNAL: 9 (Killed)". @Luc1anoo

@hongriTianqi It doesn't need any special input files, you just make two INPUT files with only the dft_functional line in lower case hse and upper case HSE, i.e. one with "dft_functional hse" and the other with "dft_functional HSE". You can easily get the similar wrong output as below: image

Luc1anoo commented 1 year ago

@Luc1anoo Thanks for your report. ABACUS will change input of dft_functional to upper case, so the error you met is abnormal. Could you please attach all the inputs for this case for us to repeat to error. Thanks.

Of course. I updated the input files in the Additional Context.I used 16 atoms system for convenience.If you set "dft_functional == hse" then the scf calculation will not start running. I used "pyatb" software package for bandstructure calculation and you will get the same band diagrams whether change the parameter "exx_hybrid_alpha". That makes me confused.

xdzhu commented 1 year ago

@Luc1anoo Thanks for your report. ABACUS will change input of dft_functional to upper case, so the error you met is abnormal. Could you please attach all the inputs for this case for us to repeat to error. Thanks.

Of course. I updated the input files in the Additional Context.I used 16 atoms system for convenience.If you set "dft_functional == hse" then the scf calculation will not start running. I used "pyatb" software package for bandstructure calculation and you will get the same band diagrams whether change the parameter "exx_hybrid_alpha". That makes me confused.

The "dft_functional hse" is the right case rather than the uppercase. You can check if there is any "EXX" in each scf cycle. If there is no EXX, then there is no hse calculation. Hybrid functional calcualtion needs more memory and more time to initialize.

Luc1anoo commented 1 year ago

@Luc1anoo Thanks for your report. ABACUS will change input of dft_functional to upper case, so the error you met is abnormal. Could you please attach all the inputs for this case for us to repeat to error. Thanks.

Of course. I updated the input files in the Additional Context.I used 16 atoms system for convenience.If you set "dft_functional == hse" then the scf calculation will not start running. I used "pyatb" software package for bandstructure calculation and you will get the same band diagrams whether change the parameter "exx_hybrid_alpha". That makes me confused.

The "dft_functional hse" is the right case rather than the uppercase. You can check if there is any "EXX" in each scf cycle. If there is no EXX, then there is no hse calculation. Hybrid functional calcualtion needs more memory and more time to initialize.

ok. Thanks for your reply! I still have two doubts: The first one is I have done a comparison between "dft_functional ==HSE" and "dft_functional == pbe", namely "default", on a 64 atoms system of Ge and apparently the former opened the bandgap(although there is still a little bit underestimation in gamma valley and L valley about 0.3eV) just like "dft_functional == XC_HYB_GGA_XC_HSE06, while the latter does not(gapless).Indeed there is never "EXX" in my scf calculation, setting "dft_functional ==HSE" still works. The second one is approximately how much memory do I need to run the relaxtion or scf with "hse"? I just tried the two format "dft_functional ==HSE" and "dft_functional == pbe" in structure relaxtion, and still the former could run successfully(except no "EXX") while the latter stoped and terminated at Initial plane wave basis and FFT box.The configuration I chose on Bohrium is c16_m32_cpu.

xdzhu commented 1 year ago

You can check this compressed file. I have put different INPUT and output in it. @hongriTianqi hse_case_issue.zip

hongriTianqi commented 1 year ago

@PeizeLin Could you please update the status of this issue? is exx_hybrid_alpha ok now? Thanks.

PeizeLin commented 1 year ago

@PeizeLin Could you please update the status of this issue? is exx_hybrid_alpha ok now? Thanks.

exx_hybrid_alpha is always ok in my tests. @Luc1anoo Does this bug still occur now? Could you try to set exx_hybrid_alpha=0 to see whether it calculates like PBE does?

By the way, dft_functional=HSE has been fixed in #2963 .

Luc1anoo commented 1 year ago

@PeizeLin Could you please update the status of this issue? is exx_hybrid_alpha ok now? Thanks.

exx_hybrid_alpha is always ok in my tests. @Luc1anoo Does this bug still occur now? Could you try to set exx_hybrid_alpha=0 to see whether it calculates like PBE does?

By the way, dft_functional=HSE has been fixed in #2963 .

This bug doesn't occur now. And I will attach my recent test below.

Luc1anoo commented 1 year ago

The mirror I'm using is abacus:3.2.3.

  1. For the "upper and lower letter" question, the result is: set 'dft_functional ==HSE' is just same as pbe(by default), instead set 'dft_functional ==hse' can perform HSE06 hybrid functional successfully. ( I tested on 2-atoms Ge primitive cell with scf&nscf calculation. The former gives zero bandgap just like pbe functional within 20 seconds total; the latter gives 0.19235 eV direct bandgap with more longer calculation time(2102 seconds), more memory costs(18690MB) and 6 times "Updating EXX and rerun SCF" total. Apparently the result is still not right( at 0K, the bandgap should be 0.74 eV for Ge and should be indirect ). Based on my experience in using vasp, the default hse parameter(0.25 for mixing parameter and 0.20 for screen parameter ) can give the right bandstructure of Ge, but the bandgap still varies from 0.2eV to 0.8eV according to lattice constant. So in order to make sure the hse hybrid functional performs well, I also tested the mixing parameter below. I noticed that dft_functional=HSE has been fixed in #2963 ", but set "dft_functional=HSE" still doesn't seem to work. Maybe I should update the mirror I guess.
  2. For the termination question, it's indeed a memory problem. The testing system is still 2-atoms Ge primitive cell. The docker "c16_m16_cpu" failed with "KILLED BY SIGNAL: 9 (Killed)" whereas "c32_m128_cpu" succeeded for hse hybrid functional calculation.
  3. I changed the mixing parameter to "exx_hybrid_alpha = 0.40" from "exx_hybrid_alpha = 0.25 ( by default )", and all other parameters is the same in "dft_functional ==hse". And I got a even more smaller bandgap( 0.15667eV ), which seems wrong in both principle and experience. But at least the parameter "exx_hybrid_alpha" indeed works.

In conclusion, I didn't optimize the crystal structure or the parameters of hse to get a accurate Ge bandstructure, but all features about ABACUS in hybrid functional seems to work well now.

Here hse-test.zip is the input files with setting "exx_hybrid_alpha = 0.40" as metioned in "3". If you delete the setting, you will get the "dft_functional == hse" test as metioned in "1". Then if you set "dft_functional == HSE", you will get the "dft_functional == HSE" test as metioned in "1".

PeizeLin commented 1 year ago

The mirror I'm using is abacus:3.2.3.

  1. For the "upper and lower letter" question, the result is: set 'dft_functional ==HSE' is just same as pbe(by default), instead set 'dft_functional ==hse' can perform HSE06 hybrid functional successfully. ( I tested on 2-atoms Ge primitive cell with scf&nscf calculation. The former gives zero bandgap just like pbe functional within 20 seconds total; the latter gives 0.19235 eV direct bandgap with more longer calculation time(2102 seconds), more memory costs(18690MB) and 6 times "Updating EXX and rerun SCF" total. Apparently the result is still not right( at 0K, the bandgap should be 0.74 eV for Ge and should be indirect ). Based on my experience in using vasp, the default hse parameter(0.25 for mixing parameter and 0.20 for screen parameter ) can give the right bandstructure of Ge, but the bandgap still varies from 0.2eV to 0.8eV according to lattice constant. So in order to make sure the hse hybrid functional performs well, I also tested the mixing parameter below. I noticed that dft_functional=HSE has been fixed in #2963 ", but set "dft_functional=HSE" still doesn't seem to work. Maybe I should update the mirror I guess.
  2. For the termination question, it's indeed a memory problem. The testing system is still 2-atoms Ge primitive cell. The docker "c16_m16_cpu" failed with "KILLED BY SIGNAL: 9 (Killed)" whereas "c32_m128_cpu" succeeded for hse hybrid functional calculation.
  3. I changed the mixing parameter to "exx_hybrid_alpha = 0.40" from "exx_hybrid_alpha = 0.25 ( by default )", and all other parameters is the same in "dft_functional ==hse". And I got a even more smaller bandgap( 0.15667eV ), which seems wrong in both principle and experience. But at least the parameter "exx_hybrid_alpha" indeed works.

In conclusion, I didn't optimize the crystal structure or the parameters of hse to get a accurate Ge bandstructure, but all features about ABACUS in hybrid functional seems to work well now.

Here hse-test.zip is the input files with setting "exx_hybrid_alpha = 0.40" as metioned in "3". If you delete the setting, you will get the "dft_functional == hse" test as metioned in "1". Then if you set "dft_functional == HSE", you will get the "dft_functional == HSE" test as metioned in "1".

v3.2.3 is released on May 19, and #2963 is on Sep 20. I strongly recommend updating the code, including ABACUS, LibRI and LibComm.

Luc1anoo commented 1 year ago

The mirror I'm using is abacus:3.2.3.

  1. For the "upper and lower letter" question, the result is: set 'dft_functional ==HSE' is just same as pbe(by default), instead set 'dft_functional ==hse' can perform HSE06 hybrid functional successfully. ( I tested on 2-atoms Ge primitive cell with scf&nscf calculation. The former gives zero bandgap just like pbe functional within 20 seconds total; the latter gives 0.19235 eV direct bandgap with more longer calculation time(2102 seconds), more memory costs(18690MB) and 6 times "Updating EXX and rerun SCF" total. Apparently the result is still not right( at 0K, the bandgap should be 0.74 eV for Ge and should be indirect ). Based on my experience in using vasp, the default hse parameter(0.25 for mixing parameter and 0.20 for screen parameter ) can give the right bandstructure of Ge, but the bandgap still varies from 0.2eV to 0.8eV according to lattice constant. So in order to make sure the hse hybrid functional performs well, I also tested the mixing parameter below. I noticed that dft_functional=HSE has been fixed in #2963 ", but set "dft_functional=HSE" still doesn't seem to work. Maybe I should update the mirror I guess.
  2. For the termination question, it's indeed a memory problem. The testing system is still 2-atoms Ge primitive cell. The docker "c16_m16_cpu" failed with "KILLED BY SIGNAL: 9 (Killed)" whereas "c32_m128_cpu" succeeded for hse hybrid functional calculation.
  3. I changed the mixing parameter to "exx_hybrid_alpha = 0.40" from "exx_hybrid_alpha = 0.25 ( by default )", and all other parameters is the same in "dft_functional ==hse". And I got a even more smaller bandgap( 0.15667eV ), which seems wrong in both principle and experience. But at least the parameter "exx_hybrid_alpha" indeed works.

In conclusion, I didn't optimize the crystal structure or the parameters of hse to get a accurate Ge bandstructure, but all features about ABACUS in hybrid functional seems to work well now. Here hse-test.zip is the input files with setting "exx_hybrid_alpha = 0.40" as metioned in "3". If you delete the setting, you will get the "dft_functional == hse" test as metioned in "1". Then if you set "dft_functional == HSE", you will get the "dft_functional == HSE" test as metioned in "1".

v3.2.3 is released on May 19, and #2963 is on Sep 20. I strongly recommend updating the code, including ABACUS, LibRI and LibComm.

ok, I will try. Thanks for your attention!

hongriTianqi commented 10 months ago

Good communications between user and developers.