kSpin(GridCalc) example gives incorrect spin texture

Top Page > Browsing

kSpin(GridCalc) example gives incorrect spin texture

Date: 2024/11/21 16:28
Name: Soichiro Kikuchi: Dear developers,

My report and question are about kSpin, especially about GridCalc.

I am trying to calculation the spin texture with GridCalc. First, I decided to try GridCalc feature and actually calculated the spin texture according to the example analysis described in the manual. The input files used are 'Au111Surface_GC.dat'.

Calculations were performed without changing the contents of the input file, but the output results were different from the Figure 66 described in the manual. In details, first, the enrgy range of band index is not output correctly. For example, the correct energy range shown in the manual for band index 55 of 'Au111Surface' is -1 to 4.5. However, the energy range of output results are 1 to 30.
Second, vectors are not displayed in the figure. Looking at the output file, we can see that some parts are displayed as 'non'.

No changes have been made, but input file used is noted.

Species.Number 2
<Definition.of.Atomic.Species
Au Au7.0-s3p2d2 Au_CA19
H H6.0-s2p1 H_CA19
Definition.of.Atomic.Species>

Atoms.Number 4
Atoms.SpeciesAndCoordinates.Unit FRAC # Ang|AU
<Atoms.SpeciesAndCoordinates
1 Au 0.10000000000000 0.33333333333333 0.66666666666667 8.5 8.5 0.0 0.0 0.0 0.0 0 off
2 Au 0.11111111111111 0.66666666666667 0.33333333333333 8.5 8.5 0.0 0.0 0.0 0.0 0 off
3 Au 0.12222222222222 0.00000000000000 0.00000000000000 8.5 8.5 0.0 0.0 0.0 0.0 0 off
4 H 0.13333333333333 0.33333333333333 0.66666666666667 0.5 0.5 0.0 0.0 0.0 0.0 0 off
Atoms.SpeciesAndCoordinates>
#5 H 0.14444444444444 0.66666666666667 0.33333333333333 0.5 0.5 0.0 0.0 0.0 0.0 0 off
#6 H 0.15555555555555 0.00000000000000 0.00000000000000 0.5 0.5 0.0 0.0 0.0 0.0 0 off

Atoms.UnitVectors.Unit Ang # Ang|AU
<Atoms.UnitVectors
211.862723 0.000000 0.000000
0.000000 2.883086 0.000000
0.000000 -1.441543 2.496826
Atoms.UnitVectors>

scf.XcType LSDA-CA # LDA|LSDA-CA|LSDA-PW
scf.SpinPolarization NC # On|Off|NC
scf.partialCoreCorrection on # On|Off
scf.Hubbard.U off # On|Off , default=off
scf.Hubbard.Occupation dual # onsite|full|dual , default=dual
scf.SpinOrbit.Coupling on # On|Off , default=off
scf.Constraint.NC.Spin off # On|Off , default=off
scf.Constraint.NC.Spin.v 1.0 # default=0.0(ev)
scf.ElectronicTemperature 100.0 # default=300 (K)
scf.energycutoff 200.0 # default=150 (Ry)
scf.maxIter 500 # default=40
scf.EigenvalueSolver Band # Recursion|Cluster|Band
scf.Kgrid 1 12 12 # means n1 x n2 x n3
scf.ProExpn.VNA on # on|off, default=on
scf.Mixing.Type Rmm-Diisk # Simple|Rmm-Diis|Gr-Pulay
scf.Init.Mixing.Weight 0.01 # default=0.30
scf.Min.Mixing.Weight 0.001 # default=0.001
scf.Max.Mixing.Weight 0.01 # default=0.40
scf.Mixing.History 30 # default=5
scf.Mixing.StartPulay 20 # default=6
scf.criterion 1.0e-8 # default=1.0e-6 (Hartree)
ESM.switch off # off, on1=v|v|v, on2=m|v|m, on3=v|v|m, on4=on2+EF
ESM.buffer.range 4.5 # default=10.0 (ang)
ESM.wall.switch on
ESM.wall.position 6.7 # default=10.0 (ang)
ESM.wall.height 100.0 # default=100.0 (eV)

1DFFT.NumGridK 900 # default=900
1DFFT.NumGridR 900 # default=900
1DFFT.EnergyCutoff 3600.0 # default=3DFFT.EnergyCutoff*3.0 (Ry)

Band.dispersion on # on|off, default=off
Band.Nkpath 3
<Band.kpath
135 0.0 0.500000 0.000000 0.0 0.000000 0.000000 M G
135 0.0 0.000000 0.000000 0.0 0.333333 0.333333 G K
135 0.0 0.333333 0.333333 0.0 0.500000 0.000000 K M
Band.kpath>

Filename.scfout Au111Surface_GC.scfout # default: default
Filename.outdata Au111Surface_GC # default: default
Calc.Type GridCalc # default: MulPOnly
Energy.Range -1.0 1.0 # eV; default: -0.5 0.5
Search.kCentral 0.0 0.0 0.0 # default: 0.0 0.0 0.0
Calc.Type.3mesh 2 # default: 1
kRange.3mesh 0.5 0.5 # default: 0.5 0.5
k-plane.1stStep 14 14 # default: 2 2
Calc.Bandbyband Off # default: Off
Calc.Band.Min 55
Calc.Band.Max 56
MulP.Vec.Scale 0.1 0.1 0.1 # default: 1.0 1.0 1.0
Filename.atomMulP Au111Surface_GC.AtomMulP # default: default
Filename.xyzdata Au111Surface_GC_MC # default: default
Num.of.Extract.Atom 3 # default: 1
Extract.Atom 1 2 3 # default: 1 2 ... (Num.of.Extract.Atom)
Data.Reduction 1 # default: 1

I would like to know that what is the cause of these problems.

Thank you very much.

Page: [1]

Re: kSpin(GridCalc) example gives incorrect spin texture ( No.1 )

Date: 2024/11/21 19:46
Name: Naoya Yamaguchi

Hi,

I checked the fragments of your input file, and indeed most of the parameters are as they were.
Based on that, I made the minimum amount of modification to the file name, etc., and was able to reproduce Figure 66.

In many cases, these problems are a matter of human error by the user.
There may be a problem with the build of OpenMX, or at least it doesn't seem to be a problem with the input file.

Regards,
Naoya Yamaguchi

Re: kSpin(GridCalc) example gives incorrect spin texture ( No.2 )

Date: 2024/11/21 22:17
Name: Soichiro Kikuchi

Dear Dr.Yamaguchi,

Thank you very much for your reply.

I will review the calculation process again.
I would appreciate it if you could tell me how you modified the file names, etc. foe reference.
In addition, I would like to know what 'the build of OpenMX' means.

Regards
Soichiro Kikuchi

Re: kSpin(GridCalc) example gives incorrect spin texture ( No.3 )

Date: 2024/11/22 04:45
Name: Naoya Yamaguchi

Dear Kikuchi-san,

>I would appreciate it if you could tell me how you modified the file names, etc. foe reference.

Except for keywords that need to be edited to match the actual computer's situation, such as `DATA.PATH`, nothing has been changed in essence.

>Looking at the output file, we can see that some parts are displayed as 'non'.

It is thought that this is `nan` (https://ja.wikipedia.org/wiki/NaN ), but if this is the case, there is a problem with the creation of the `kSpin` or `openmx` executable file, and it is presumed that some kind of problem is occurring on your computer.

If the build is a problem, it will be necessary to carry out a detailed review, such as reviewing the compilation and linking methods.

At the very least, we confirmed that the input file bundled with OpenMX worked correctly when it was released.

Regards,
Naoya Yamaguchi

Page: [1]