 Re: Totally wrong convergence in supercell ( No.1 ) |
- Date: 2020/06/29 13:05
- Name: Naoya Yamaguchi
- Hi,
You use the same setting for "Band.kpath" in the super cell as the primitive cell.
Band.dispersion on # on|off, default=off
Band.Nkpath 2
<Band.kpath
60 0.00000000 -0.50000000 0.00000000 0.00000000 0.00000000 0.00000000 M G
60 0.00000000 0.00000000 0.00000000 0.00000000 0.50000000 0.00000000 G M
Band.kpath>
I think that one of k-paths in the super cell doesn't correspond the path between the special high symmetry points such as the Gamma-point in the primitive cell because the reciprocal lattice vector is also different between the super cell and primitive cell. So, I wonder if your comparison is correct. Although in order to check if you get the correct band dispersion, you need to compare energies at the corresponding k-points right, you can use the band unfolding method to compare them intuitively:
http://www.openmx-square.org/openmx_man3.9/node167.html
Regards,
Naoya Yamaguchi
|
| Re: Totally wrong convergence in supercell ( No.2 ) |
- Date: 2020/06/29 13:14
- Name: Zuzhang Lin <linzz16@mails.tsinghua.edu.cn>
- Dear Naoya Yamaguchi,
Thank you for your help.
Though I use the same Band.kpath" in the super cell as the primitive cell, I can still tell the bandstructure is wrong. 1) the illustration of the bandstructure of the supercell is totally a mass. I hope I can send you the picture by some other ways if you like.2) The monolayer MoSe2 is an insulator with direct band gap. I found the band gap of the supercell is not consistent with the primitive one.3)I also run the exactly same structure by VASP. I find the band from VASP is reasonable. So I doublt the convergence of the supercell in openmx is totally wrong.
|
| Re: Totally wrong convergence in supercell ( No.3 ) |
- Date: 2020/06/30 02:50
- Name: Naoya Yamaguchi
- Dear Zuzhang Lin,
I tried your input file of the super cell, but now the number of iteration cycles in the SCF calculation exceeds 1000, and the SCF convergence is not obtained. So, I wonder if your calculation of the super cell reached the convergence. Please check how your calculation was finished.
>Though I use the same Band.kpath" in the super cell as the primitive cell, I can still tell the bandstructure is wrong.
As I said in the previous post, I can't see what you compared by using the same "Band.kpath".
>1) the illustration of the bandstructure of the supercell is totally a mass. I hope I can send you the picture by some other ways if you like.
You may use some cloud services such as Github and Dropbox to share your cases.
>2) The monolayer MoSe2 is an insulator with direct band gap. I found the band gap of the supercell is not consistent with the primitive one.
As I searched some articles, and the direct band gap appears at the K-point (1/3, 1/3, 0) (in the case of a primitive cell). How did you calculate the band gap in the case of the super cell?
>3)I also run the exactly same structure by VASP. I find the band from VASP is reasonable. So I doublt the convergence of the supercell in openmx is totally wrong.
I think that if this problem is caused by the poor description of the electronic structure that doesn't satisfy the convergence, you should adjust parameters about SCF calculations to get the convergence.
Regards,
Naoya Yamaguchi
 |
| Re: Totally wrong convergence in supercell ( No.4 ) |
- Date: 2020/06/30 09:34
- Name: Zuzhang Lin <linzz16@mails.tsinghua.edu.cn>
- Dear Naoya Yamaguchi,
Thank you for your message.
It is strange SCF convergence was not abtained untill 1000 cycles in your case. In my case, it reached the SCF convergence at cycle 76. I have put the output file "met.std" on https://github.com/Diversitylin/openmxresults.In the end of the file, it tells "The calculation was normally finished."
I should have made my problem clearer. I am sorry for the inconvenience.
>1) As I said in the previous post, I can't see what you compared by using the same "Band.kpath".
I put my resutlts here: https://github.com/Diversitylin/openmxresults. As you can see the band of the supercell is unreasonable and can not be ture.
>2) The monolayer MoSe2 is an insulator with direct band gap. I found the band gap of the supercell is not consistent with the primitive one.
The results of the supercell show it is a metal.There is no way we get a smaller band gap when we are calculating the supercell.So it can not be true since the band of the primitive cell show it is an insulator.
>3)I think that if this problem is caused by the poor description of the electronic structure that doesn't satisfy the convergence, you should adjust parameters about SCF calculations to get the convergence.
Because the output file "met.std" tells "The calculation was normally finished.", I naively think my calculation has reached the convergence.As I have said, the band of the supercell from the openmx tells it becomes a metal. For Vasp,I cheked the band gap at Gamm point, which is the same with primitive ones.
Regards,
Zuzhang Lin
|
| Re: Totally wrong convergence in supercell ( No.5 ) |
- Date: 2020/06/30 09:36
- Name: Zuzhang Lin <linzz16@mails.tsinghua.edu.cn>
- The website should be https://github.com/Diversitylin/openmxresults.git
Sorry for that
|
| Re: Totally wrong convergence in supercell ( No.6 ) |
- Date: 2020/06/30 13:03
- Name: Naoya Yamaguchi
- Dear Zuzhang Lin,
Can you also show *.out?
And I think that "Ver. 3.822" is a disclosed version, and I use "Ver. 3.9.2".
As such, it may be difficult for me to reproduce your case that the metallic bands appear as the PNG file shows if *.out shows the same input file.
At least, "Mo_CA13" and "Se_CA13" should be "Mo_PBE13" and "Se_PBE13", respectively since the value for "scf.XcType" is "GGA-PBE".
Regards,
Naoya Yamaguchi
|
| Re: Totally wrong convergence in supercell ( No.7 ) |
- Date: 2020/06/30 16:47
- Name: Zuzhang Lin <linzz16@mails.tsinghua.edu.cn>
- Dear Naoya Yamaguchi,
Thank you for your message. I have put the *.out file on https://github.com/Diversitylin/openmxresults.git . You can also check the whole directories if you like (the *.scfout file was deleted).
I also have done a test run when I use "Mo_CA19" and "Se_CA19", it gave the same results. I will see if using "Mo_PBE19" and "Se_PBE19" will help or not.
Regards,
Zuzhang Lin
|
| Re: Totally wrong convergence in supercell ( No.8 ) |
- Date: 2020/07/01 14:59
- Name: Naoya Yamaguchi
- Dear Zuzhang Lin,
I have reproduced your case that shows the metallic electronic structure by modifying some parameters such as the mixing, and I show the beginning of *.out:
***********************************************************
***********************************************************
This calculation was performed by OpenMX Ver. 3.9.2
using 64 MPI processes and 1 OpenMP threads.
Wed Jul 1 02:27:32 2020
***********************************************************
***********************************************************
System.Name 2649_SC
#
# Definition of Atomic Species
#
Species.Number 2
#<Definition.of.Atomic.Species
#Mo Mo7.0-s2p2d1 Mo_CA13
#Se Se8.0-s3p3d2 Se_CA13
#Definition.of.Atomic.Species>
<Definition.of.Atomic.Species
Mo Mo7.0-s2p2d1 Mo_PBE19
Se Se8.0-s3p3d2 Se_PBE19
Definition.of.Atomic.Species>
Atoms.Number 36
Atoms.SpeciesAndCoordinates.Unit Ang
<Atoms.SpeciesAndCoordinates
1 Mo 4.965223209 6.688903565 13.185977001 7.0 7.0
2 Mo 6.620297612 9.555576521 13.185977001 7.0 7.0
3 Mo 8.275372014 12.422249477 13.185977001 7.0 7.0
4 Mo 9.930446417 15.288922433 13.185977001 7.0 7.0
5 Mo 11.585520820 18.155595390 13.185977001 7.0 7.0
6 Mo 13.240595223 21.022268346 13.185977001 7.0 7.0
7 Mo 14.895669625 23.888941302 13.185977001 7.0 7.0
8 Mo 16.550744028 26.755614258 13.185977001 7.0 7.0
9 Mo 18.205818431 29.622287215 13.185977001 7.0 7.0
10 Mo 19.860892834 32.488960171 13.185977001 7.0 7.0
11 Mo 21.515967236 35.355633127 13.185977001 7.0 7.0
12 Mo 23.171041639 38.222306083 13.185977001 7.0 7.0
13 Se 9.930446417 13.377807129 14.852684494 3.0 3.0
14 Se 11.585520820 16.244480086 14.852684494 3.0 3.0
15 Se 13.240595223 19.111153042 14.852684494 3.0 3.0
16 Se 14.895669625 21.977825998 14.852684494 3.0 3.0
17 Se 16.550744028 24.844498954 14.852684494 3.0 3.0
18 Se 18.205818431 27.711171911 14.852684494 3.0 3.0
19 Se 19.860892834 30.577844867 14.852684494 3.0 3.0
20 Se 21.515967236 33.444517823 14.852684494 3.0 3.0
21 Se 23.171041639 36.311190779 14.852684494 3.0 3.0
22 Se 24.826116042 39.177863736 14.852684494 3.0 3.0
23 Se 26.481190445 42.044536692 14.852684494 3.0 3.0
24 Se 28.136264847 44.911209648 14.852684494 3.0 3.0
25 Se 9.930446417 13.377807129 11.519269508 3.0 3.0
26 Se 11.585520820 16.244480086 11.519269508 3.0 3.0
27 Se 13.240595223 19.111153042 11.519269508 3.0 3.0
28 Se 14.895669625 21.977825998 11.519269508 3.0 3.0
29 Se 16.550744028 24.844498954 11.519269508 3.0 3.0
30 Se 18.205818431 27.711171911 11.519269508 3.0 3.0
31 Se 19.860892834 30.577844867 11.519269508 3.0 3.0
32 Se 21.515967236 33.444517823 11.519269508 3.0 3.0
33 Se 23.171041639 36.311190779 11.519269508 3.0 3.0
34 Se 24.826116042 39.177863736 11.519269508 3.0 3.0
35 Se 26.481190445 42.044536692 11.519269508 3.0 3.0
36 Se 28.136264847 44.911209648 11.519269508 3.0 3.0
Atoms.SpeciesAndCoordinates>
Atoms.UnitVectors.Unit Ang
<Atoms.UnitVectors
14.895669625 20.066710694 0.000000000
19.860892833 34.400075475 0.000000000
0.000000000 0.000000000 26.371954002
Atoms.UnitVectors>
scf.XcType GGA-PBE # LDA|LSDA-CA|LSDA-PW
scf.SpinPolarization NC # On|Off
scf.ElectronicTemperature 300.0 # default=300 (K)
scf.energycutoff 200.0 # default=150 (Ry)
scf.maxIter 10000 # default=40
scf.EigenvalueSolver Band # DC|Cluster|Band
scf.Kgrid 10 10 1
scf.Mixing.Type rmm-diisv # Simple|Rmm-Diis|Gr-Pulay
scf.Init.Mixing.Weight 0.1 # default=0.30
scf.Min.Mixing.Weight 0.001 # default=0.001
scf.Max.Mixing.Weight 0.1 # default=0.40
scf.Mixing.History 10 # default=5
scf.Mixing.StartPulay 10 # default=6
scf.criterion 1.0e-9 # default=1.0e-6 (Hartree)
scf.Electric.Field 0.0 0.0 0.0 # default=0.0 0.0 0.0 (GV/m)
scf.SpinOrbit.Coupling on
scf.restart off
HS.fileout on # on|off, default=off
Band.dispersion on # on|off, default=off
Band.Nkpath 2
<Band.kpath
60 0.00000000 -0.50000000 0.00000000 0.00000000 0.00000000 0.00000000 M G
60 0.00000000 0.00000000 0.00000000 0.00000000 0.50000000 0.00000000 G M
Band.kpath>
MO.fileout off # on|off, default=off
num.HOMOs 1 # default=1
num.LUMOs 1 # default=1
scf.fixed.grid 0.00000000000000 0.00000000000000 0.00000000000000
***********************************************************
***********************************************************
Required cutoff energy (Ryd) for 3D-grids = 200.0000
Used cutoff energy (Ryd) for 3D-grids = 193.7172, 212.9993, 199.3946
Num. of grids of a-, b-, and c-axes = 24, 40, 224
Num.Grid1. 24
Num.Grid2. 40
Num.Grid3. 224
Cell_Volume = 20264.959025843582 (Bohr^3)
GridVol = 0.094238090708 (Bohr^3)
Cell vectors (bohr) of the grid cell (gtv)
gtv_a = 1.172863916985, 1.580024362656, 0.000000000000
gtv_b = 0.938291133573, 1.625167915855, 0.000000000000
gtv_c = 0.000000000000, 0.000000000000, 0.222481101996
|gtv_a| = 1.967761864239
|gtv_b| = 1.876582267332
|gtv_c| = 0.222481101996
***********************************************************
***********************************************************
Following the input, information of cutoff energy and grids appears, and the lengths of gtv_a and gtv_b appears too rough because they reach ~1 angstrom.
So, I changed the number of grids along a-, and b-axes manually by setting "scf.Ngrid" and I got the reasonable result.
The following is *.out for the modified calculation.
***********************************************************
***********************************************************
This calculation was performed by OpenMX Ver. 3.9.2
using 64 MPI processes and 1 OpenMP threads.
Wed Jul 1 14:22:54 2020
***********************************************************
***********************************************************
System.Name 2649_SC_revrev2
#
# Definition of Atomic Species
#
Species.Number 2
#<Definition.of.Atomic.Species
#Mo Mo7.0-s2p2d1 Mo_CA13
#Se Se8.0-s3p3d2 Se_CA13
#Definition.of.Atomic.Species>
<Definition.of.Atomic.Species
Mo Mo7.0-s3p2d2f1 Mo_PBE19
Se Se7.0-s3p2d2f1 Se_PBE19
Definition.of.Atomic.Species>
Atoms.Number 36
Atoms.SpeciesAndCoordinates.Unit Ang
<Atoms.SpeciesAndCoordinates
1 Mo 4.965223209 6.688903565 13.185977001 7.0 7.0
2 Mo 6.620297612 9.555576521 13.185977001 7.0 7.0
3 Mo 8.275372014 12.422249477 13.185977001 7.0 7.0
4 Mo 9.930446417 15.288922433 13.185977001 7.0 7.0
5 Mo 11.585520820 18.155595390 13.185977001 7.0 7.0
6 Mo 13.240595223 21.022268346 13.185977001 7.0 7.0
7 Mo 14.895669625 23.888941302 13.185977001 7.0 7.0
8 Mo 16.550744028 26.755614258 13.185977001 7.0 7.0
9 Mo 18.205818431 29.622287215 13.185977001 7.0 7.0
10 Mo 19.860892834 32.488960171 13.185977001 7.0 7.0
11 Mo 21.515967236 35.355633127 13.185977001 7.0 7.0
12 Mo 23.171041639 38.222306083 13.185977001 7.0 7.0
13 Se 9.930446417 13.377807129 14.852684494 3.0 3.0
14 Se 11.585520820 16.244480086 14.852684494 3.0 3.0
15 Se 13.240595223 19.111153042 14.852684494 3.0 3.0
16 Se 14.895669625 21.977825998 14.852684494 3.0 3.0
17 Se 16.550744028 24.844498954 14.852684494 3.0 3.0
18 Se 18.205818431 27.711171911 14.852684494 3.0 3.0
19 Se 19.860892834 30.577844867 14.852684494 3.0 3.0
20 Se 21.515967236 33.444517823 14.852684494 3.0 3.0
21 Se 23.171041639 36.311190779 14.852684494 3.0 3.0
22 Se 24.826116042 39.177863736 14.852684494 3.0 3.0
23 Se 26.481190445 42.044536692 14.852684494 3.0 3.0
24 Se 28.136264847 44.911209648 14.852684494 3.0 3.0
25 Se 9.930446417 13.377807129 11.519269508 3.0 3.0
26 Se 11.585520820 16.244480086 11.519269508 3.0 3.0
27 Se 13.240595223 19.111153042 11.519269508 3.0 3.0
28 Se 14.895669625 21.977825998 11.519269508 3.0 3.0
29 Se 16.550744028 24.844498954 11.519269508 3.0 3.0
30 Se 18.205818431 27.711171911 11.519269508 3.0 3.0
31 Se 19.860892834 30.577844867 11.519269508 3.0 3.0
32 Se 21.515967236 33.444517823 11.519269508 3.0 3.0
33 Se 23.171041639 36.311190779 11.519269508 3.0 3.0
34 Se 24.826116042 39.177863736 11.519269508 3.0 3.0
35 Se 26.481190445 42.044536692 11.519269508 3.0 3.0
36 Se 28.136264847 44.911209648 11.519269508 3.0 3.0
Atoms.SpeciesAndCoordinates>
Atoms.UnitVectors.Unit Ang
<Atoms.UnitVectors
14.895669625 20.066710694 0.000000000
19.860892833 34.400075475 0.000000000
0.000000000 0.000000000 26.371954002
Atoms.UnitVectors>
scf.XcType GGA-PBE # LDA|LSDA-CA|LSDA-PW
scf.SpinPolarization NC # On|Off
scf.ElectronicTemperature 300.0 # default=300 (K)
scf.energycutoff 200.0 # default=150 (Ry)
scf.NGrid 182 290 224
scf.maxIter 10000 # default=40
scf.EigenvalueSolver Band # DC|Cluster|Band
scf.Kgrid 7 5 1
scf.Mixing.Type rmm-diisv # Simple|Rmm-Diis|Gr-Pulay
scf.Init.Mixing.Weight 0.1 # default=0.30
scf.Min.Mixing.Weight 0.001 # default=0.001
scf.Max.Mixing.Weight 0.1 # default=0.40
scf.Mixing.History 10 # default=5
scf.Mixing.StartPulay 10 # default=6
scf.criterion 1.0e-8 # default=1.0e-6 (Hartree)
scf.Electric.Field 0.0 0.0 0.0 # default=0.0 0.0 0.0 (GV/m)
scf.SpinOrbit.Coupling on
scf.restart off
HS.fileout off # on|off, default=off
Band.dispersion on # on|off, default=off
Band.Nkpath 2
<Band.kpath
60 0.00000000 -0.50000000 0.00000000 0.00000000 0.00000000 0.00000000 M G
60 0.00000000 0.00000000 0.00000000 0.00000000 0.50000000 0.00000000 G M
Band.kpath>
MO.fileout off # on|off, default=off
num.HOMOs 1 # default=1
num.LUMOs 1 # default=1
scf.fixed.grid 0.00000000000000 0.00000000000000 0.00000000000000
***********************************************************
***********************************************************
Required cutoff energy (Ryd) for 3D-grids = 7511.7517
Used cutoff energy (Ryd) for 3D-grids = 11140.0862, 11195.7743, 199.3946
Num. of grids of a-, b-, and c-axes = 182, 290, 224
Num.Grid1. 182
Num.Grid2. 290
Num.Grid3. 224
Cell_Volume = 20264.959025843582 (Bohr^3)
GridVol = 0.001714069100 (Bohr^3)
Cell vectors (bohr) of the grid cell (gtv)
gtv_a = 0.154663373668, 0.208354861010, 0.000000000000
gtv_b = 0.129419466700, 0.224161091842, 0.000000000000
gtv_c = 0.000000000000, 0.000000000000, 0.222481101996
|gtv_a| = 0.259485080999
|gtv_b| = 0.258838933425
|gtv_c| = 0.222481101996
***********************************************************
***********************************************************
I also changed the setting of PAOs following http://www.openmx-square.org/openmx_man3.9/node27.html and adjust values for "scf.Kgrid".
And, I used rougher "scf.criterion" of "1.0e-8" and didn't check DOS. Please calculate and investigate it by yourself by referring to the above.
I wonder if this problem is caused by the wrong estimation of the number of grids by OpenMX, and one can avoid it by using "scf.Ngrid".
For your information, I also leave information of grids in the case of the primitive cell, and this is why I set "scf.NGrid 182 290 224":
***********************************************************
***********************************************************
Required cutoff energy (Ryd) for 3D-grids = 200.0000
Used cutoff energy (Ryd) for 3D-grids = 193.7172, 193.7172, 199.3946
Num. of grids of a-, b-, and c-axes = 24, 24, 224
Num.Grid1. 24
Num.Grid2. 24
Num.Grid3. 224
Cell_Volume = 1688.746585540872 (Bohr^3)
GridVol = 0.013088623710 (Bohr^3)
Cell vectors (bohr) of the grid cell (gtv)
gtv_a = 0.260636426032, 0.000000000000, 0.000000000000
gtv_b = 0.130318213016, 0.225717766071, 0.000000000000
gtv_c = 0.000000000000, 0.000000000000, 0.222481101996
|gtv_a| = 0.260636426032
|gtv_b| = 0.260636426011
|gtv_c| = 0.222481101996
***********************************************************
***********************************************************
Regards,
Naoya Yamaguchi
|
| Re: Totally wrong convergence in supercell ( No.9 ) |
- Date: 2020/07/01 21:27
- Name: Zuzhang Lin <linzz16@mails.tsinghua.edu.cn>
- Dear Naoya Yamaguchi,
Thank you very much. I am running the job by setting "scf. Ngrid" as you recommended. I find my job terminated suddenly. At the end of the *std file, it reads
*******************************************************
SCF calculation at MD = 1
*******************************************************
<MD= 1> Calculation of the overlap matrix
===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= RANK 0 PID 27127 RUNNING AT node42.cluster
= KILLED BY SIGNAL: 9 (Killed)
===================================================================================.
Usually, such a thing happens when the job runs out of the memory of the cluster in our group. Then I began to use more GPUs to run the job. But it still terminated even if I use 5 GPUs (24 cores, 96G memory for each GPU). Do you have any ideas about the bad termination of my job?
I appreciated that you kindly answer my question with much patience all the time.
Regards,
Zuzhang Lin
|
| Re: Totally wrong convergence in supercell ( No.10 ) |
- Date: 2020/07/02 03:54
- Name: Naoya Yamaguchi
- Dear Zuzhang Lin,
>Usually, such a thing happens when the job runs out of the memory of the cluster in our group. Then I began to use more GPUs to run the job. But it still terminated even if I use 5 GPUs (24 cores, 96G memory for each GPU). Do you have any ideas about the bad termination of my job?
The machine I used for this calculation allocates memory of 256GB. So, maybe in my case, the problem doesn't occur.
OpenMX doesn't use GPUs and anyway you need to allocate enough amount of memory or to reduce the required amount.
To reduce the required memory, you can reduce the accuracy.
For example, you can remove f-character orbitals.
<Definition.of.Atomic.Species
Mo Mo7.0-s3p2d2 Mo_PBE19
Se Se7.0-s3p2d2 Se_PBE19
Definition.of.Atomic.Species>
And decreasing the number of MPI processes might be effective.
Although I set first the value for "scf.Ngrid" as |gtv_a| and |gtv_b| in the case of the super cell is similar to those in the case of the primitive cell, but I think that it is better to set it in terms of the area or volume to consider the reasonable discretization. So, for example, "scf.NGrid 66 105 224".
Regards,
Naoya Yamaguchi
|
| Re: Totally wrong convergence in supercell ( No.11 ) |
- Date: 2020/07/02 09:45
- Name: Zuzhang Lin <linzz16@mails.tsinghua.edu.cn>
- Dear Naoya Yamaguchi,
Thank you very much. I have fixed all the problems and got reasonable results. I am sorry for the GPUs I mentioned. I am not familiar with such a thing. In our machine, we have 24 cores for 1 node (96 for memory). If we use more than one node to run a vasp job, usually we should set some parameters to make use of as much memory as possible. Anyway, I have reduced the amount as you suggested. Thank you for all the advice. It helps me a lot.
Regards,
Zuzhang Lin
|
|
This thread is locked.Only browsing is available.
Totally wrong convergence in supercell