 Re: Absolute core electron binding energies with surface slab ( No.1 ) |
- Date: 2021/06/09 20:59
- Name: T. Ozaki
- Hi,
The absolute binding energy method has been successfully applied to slab systems including
"Single-particle excitation of core states in epitaxial silicene",
C.-C. Lee et al., Phys. Rev. B 95, 115437 (2017).
"Peculiar bonding associated with atomic doping and hidden honeycombs in borophene",
C.-C. Lee et al., Phys. Rev. B 97, 075430 (2018).
"Atomic Structure and Local Electronic States of Single Pt Atoms Dispersed on Graphene",
K. Yamazaki et al., J. Phys. Chem. C 122, 27292-27300 (2018).
"Emergence of nearly flat bands through a kagome lattice embedded in an epitaxial two-dimensional Ge layer with a bitriangular structure",
A. Fleurence et al., Phys. Rev. B 102, 201102(R) (2020).
I wonder that you have propely set parameters such as basis functions as explaned at
http://www.openmx-square.org/openmx_man3.9/node192.html
http://www.openmx-square.org/openmx_man3.9/node193.html
Have you tried much simpler slab systems?
If you cannot get a proper binding energy even for such a simpler system, this indicates that
your input file may have an inproper setting.
Regards,
TO
 |
| Re: Absolute core electron binding energies with surface slab ( No.2 ) |
- Date: 2021/06/09 22:55
- Name: Pavel Ondracka <pavel.ondracka@email.cz>
- It works for me for bulks, but it is possible I have some stupid mistake in my slab calculations, here is the initial state input:
https://drive.google.com/file/d/1J0vqj-qybIP6B1iuyPQlMIzYnDCyidJy/view?usp=sharing
and here the final state input (starting from the initial state restart files):
https://drive.google.com/file/d/1gvryMvz7fo_MnD_H4gvF64UGt-TrKBqo/view?usp=sharing
If you can spot anything obviously wrong there, I would be grateful for comments.
|
| Re: Absolute core electron binding energies with surface slab ( No.3 ) |
- Date: 2021/06/09 22:58
- Name: Pavel Ondracka <pavel.ondracka@email.cz>
- To make some digest, the basis set I use is:
Species.Number 8
<Definition.of.Atomic.Species
H H6.0-s2p1 H_PBE19
C C7.0_1s-s4p3d2 C_PBE19_1s
C1 C7.0_1s_CH-s4p3d2 C_PBE19_1s
O O7.0_1s-s4p3d2 O_PBE19_1s
O1 O7.0_1s_CH-s4p3d2 O_PBE19_1s
N N7.0_1s-s4p3d2 N_PBE19_1s
N1 N7.0_1s_CH-s4p3d2 N_PBE19_1s
Ti Ti7.0-s3p2d1 Ti_PBE19
Definition.of.Atomic.Species>
where in the initial state all atoms have the standard basis set and in the final state the specific one atom has the CH basis (carbon atom number 605 in the posted dat files).
The relevant settings for the final state example look like this:
scf.system.charge 1.0
scf.restart on
scf.coulomb.cutoff on
scf.core.hole on
<core.hole.state
605 s 1
core.hole.state>
|
| Re: Absolute core electron binding energies with surface slab ( No.4 ) |
- Date: 2021/06/09 23:45
- Name: T. Ozaki
- Hi,
I noticed that scf.restart.filename is not specified in your input file for the final state calculation.
As an example, an input file of charged case (scf.system.charge 1.0) can be found for diamond bulk at:
https://t-ozaki.issp.u-tokyo.ac.jp/vps_pao_core2019/C/DIA-5-CH.dat
The following is the relevant keywords:
scf.restart on
scf.restart.filename DIA-5
scf.coulomb.cutoff on
scf.core.hole on
<core.hole.state
1 s 1
core.hole.state>
scf.system.charge 1.0
The keyword 'scf.restart.filename' specifies the periodic density of the initial state, which is used to calculate
the induced density by the core hole creation. For the induced density the interaction between replicated cells is
cut by the exact Coulomb cutoff method. The idea is explained around the bottom of the left column in the page 3 at
http://www.openmx-square.org/tech_notes/XPS_Core_Level.pdf
I also noticed that you are using the same system.name as
System.Name abc
It would be better to use a different system.name, since the name is referred to as scf.restart.filename.
I also wonder the metallic treatment:
scf.restart off
scf.coulomb.cutoff off
scf.core.hole on
<core.hole.state
605 s 1
core.hole.state>
may give a good result because of metallicity of TiN which must lead to a strong screeing for the created core hole.
Many examples for input files can be found at
https://t-ozaki.issp.u-tokyo.ac.jp/vps_pao_core2019/
for reference.
Regards,
TO
|
| Re: Absolute core electron binding energies with surface slab ( No.5 ) |
- Date: 2021/06/10 04:07
- Name: Pavel Ondracka <pavel.ondracka@email.cz>
- My intended workflow is to do the initial state calculation, i.e., with the example initial-state.dat file as attached above and than I make a new directory, where I copy the restart directory from the initial state calculations and run the final-state.dat there (I want to run multiple final state calculations eventually for different atoms eventully, so I can't run in the same directory as they will overwrite the initial state restart files, right?). So if I understand it properly the identical system name should not be an issue? BTW I've double-checked that the restart files from the initial state calculations are indeed being read properly.
Regarding the metallic treatment, I'm not so sure myself, the slab is conductive, but the molecule is not, so I used "scf.system.charge 1.0 " just to play it safe. You think it would make sense to use "scf.system.charge 0" when calculating C1s core levels of the molecule?
I should also note that I'm having some convergence problems with the final state calculations, I had to increase temperature to 1000K and I can't converge it much better than the "scf.criterion 2.0e-4". But this should IMO cause uncertainty of few tens of eV maximum not hundred.
|
| Re: Absolute core electron binding energies with surface slab ( No.6 ) |
- Date: 2021/06/10 04:10
- Name: Pavel Ondracka <pavel.ondracka@email.cz>
- BTW the exact Coulomb cutoff is only important for absolute BEs, right? So if I say relative shifts are enough, than it in theory should not matter?
|
| Re: Absolute core electron binding energies with surface slab ( No.7 ) |
- Date: 2021/06/10 09:52
- Name: T. Ozaki
- Hi,
My calculations with the following basis functions
<Definition.of.Atomic.Species
H H6.0-s2p1 H_PBE19
C C7.0_1s-s3p2d1 C_PBE19_1s
C1 C7.0_1s_CH-s2p2d1 C_PBE19_1s
O O7.0_1s-s3p2d1 O_PBE19_1s
O1 O7.0_1s_CH-s3p2d1 O_PBE19_1s
N N7.0_1s-s3p2d1 N_PBE19_1s
N1 N7.0_1s_CH-s3p2d1 N_PBE19_1s
Ti Ti7.0-s3p2d1 Ti_PBE19
Definition.of.Atomic.Species>
can be seen at
the initial state calculation:
http://www.openmx-square.org/forum/img/initial-state.dat
http://www.openmx-square.org/forum/img/initial-state.out
the final state calculation: scf.system.charge=1.0 (general treatment)
http://www.openmx-square.org/forum/img/final-state.dat
http://www.openmx-square.org/forum/img/final-state.out
the final state calculation: scf.system.charge=0.0 (metallic treatment)
http://www.openmx-square.org/forum/img/final-state2.dat
http://www.openmx-square.org/forum/img/final-state2.out
The binding energy of C-1s is calculated as
scf.system.charge=1.0 (general treatment);
Eb = -33034.278663261270 - (-33044.928704810773) - 0.27233927024260 = 10.3777 Hartree = 282.39 eV
scf.system.charge=0.0 (metallic treatment)
Eb = -33034.564043873535 - (-33044.928704810773) = 10.3647 Hartree = 282.04 eV
The difference between the two methods is 0.35 eV.
The reason why I used the basis functions being a relatively smaller number of basis function compared to yours
is that I was concerned about the possible overcompleteness problem. I hope that you can confirm whether
it is a matter or not.
To me, the calculations look normal, and the obtained binding energies are also acceptable.
(Would it be possible to let us know the experimental value just for reference?)
Regards,
TO
|
| Re: Absolute core electron binding energies with surface slab ( No.8 ) |
- Date: 2021/06/10 16:03
- Name: Pavel Ondracka <pavel.ondracka@email.cz>
- Ah, OK so the basis set seems to be the case, I'll try to experiment with that more. I used more basis function because that is what the examples use as well, for example here:
http://www.openmx-square.org/openmx_man3.9/node192.html is used
C C7.0_1s-s4p3d2 C_PBE19_1s
for organic molecule. I need to do more reading about the overcompleteness problem. Manual claims this is an issue for dense bulks, so in my case it should be the case for the TiN but I've tried to use
N N6.0-s2p2d1 N_PBE19
previously and there was almost no change, so one really needs to reduce the number of basis function in the molecule on top as well.
BTW I don't understand why you use a different number of basis functions for the normal carbon and the one with corehole, is that a typo or intentional?
C C7.0_1s-s3p2d1 C_PBE19_1s
C1 C7.0_1s_CH-s2p2d1 C_PBE19_1s
Regarding the experimental part, this is my stupid try how to model polycarbonate interaction with surfaces, I can't really model the polymer, so I went for dimer for now (I have some MD runs where I let it interact on its own, but this model was just simple handcrafted one). However, for this example I selected C atom from CH3 group not directly on the surface, so the BE should have probably standard BE of aliphatic carbon, around 284.8eV. In that regard ~282eV is a bit too low, but still 100eV closer than before so this is starting to look good. :-)
|
| Re: Absolute core electron binding energies with surface slab ( No.9 ) |
- Date: 2021/06/10 21:02
- Name: T. Ozaki
- Hi,
> BTW I don't understand why you use a different number of basis functions for the normal carbon and the
> one with corehole, is that a typo or intentional?
> C C7.0_1s-s3p2d1 C_PBE19_1s
> C1 C7.0_1s_CH-s2p2d1 C_PBE19_1s
This is my simple mistake.
With the following basis functions:
<Definition.of.Atomic.Species
H H6.0-s2p1 H_PBE19
C C7.0_1s-s3p2d1 C_PBE19_1s
C1 C7.0_1s_CH-s3p2d1 C_PBE19_1s
O O7.0_1s-s3p2d1 O_PBE19_1s
O1 O7.0_1s_CH-s3p2d1 O_PBE19_1s
N N7.0_1s-s3p2d1 N_PBE19_1s
N1 N7.0_1s_CH-s3p2d1 N_PBE19_1s
Ti Ti7.0-s3p2d1 Ti_PBE19
Definition.of.Atomic.Species>
I got the following binding energy of C-1s:
scf.system.charge=1.0 (general treatment);
Eb = -33034.279508746615 - (-33044.928704122569) - 0.272339324543 = 10.3769 Hartree = 282.37 eV
scf.system.charge=0.0 (metallic treatment)
Eb = -33034.564877063742 - (-33044.928704122569) = 10.3638 Hartree = 282.01 eV
The change is quite small compared to the previous case.
In addition to this, I have calculated the case of the basis functions you specified as
<Definition.of.Atomic.Species
H H6.0-s2p1 H_PBE19
C C7.0_1s-s4p3d2 C_PBE19_1s
C1 C7.0_1s_CH-s4p3d2 C_PBE19_1s
O O7.0_1s-s4p3d2 O_PBE19_1s
O1 O7.0_1s_CH-s4p3d2 O_PBE19_1s
N N7.0_1s-s4p3d2 N_PBE19_1s
N1 N7.0_1s_CH-s4p3d2 N_PBE19_1s
Ti Ti7.0-s3p2d1 Ti_PBE19
Definition.of.Atomic.Species>
and obtained the following binding energy of C-1s:
scf.system.charge=1.0 (general treatment);
Eb = -33036.612741593235 - (-33047.257879308650) -0.26627412657562 = 10.3789 Hartree = 282.42 eV
The obtained binding energy is close to the case with the smlaller basis functions, which implies
that the overcompleness problem is NOT the origin for your erratic result.
The following is the output files for your reference:
http://www.openmx-square.org/forum/img/is0.out
http://www.openmx-square.org/forum/img/fs0.out
> the BE should have probably standard BE of aliphatic carbon, around 284.8eV.
It is likely that the binding energy varies due to at least two factors:
One is that the carbon atom that we calculated the binding energy of C-1s is close to the TiN surface,
the other is the chemical potential of TiN. The two factors might be responcilble for changing the
binding energy of C-1s.
Regards,
TO
|
| Re: Absolute core electron binding energies with surface slab ( No.10 ) |
- Date: 2021/06/10 21:11
- Name: Pavel Ondracka <pavel.ondracka@email.cz>
- I don't understand this, the initial state output run looks similar to my, but the final state is completely different. As far as I can see you only somehow tweaked the mixing
< scf.Max.Mixing.Weight 0.20
---
> scf.Max.Mixing.Weight 0.30
but the input is the same otherwise.
However my final total energy is very different.
< Utot. -33036.612741593235
---
> Utot. -33040.685365210120
Here is the complete .out file: https://drive.google.com/file/d/1zMCm5HiYqTwPHbzTlqfYk1anphOlg6HK/view?usp=sharing
It seems the mixing is indeed somehow problematic, in your run the first steps look like this:
< SCF= 1 NormRD= 1.000000000000 Uele= -14410.983632723679
< SCF= 2 NormRD= 27.913121068539 Uele= -14410.983632723735
< SCF= 3 NormRD= 27.776187515766 Uele= -14411.645187054999
< SCF= 4 NormRD= 22.367871971930 Uele= -14437.977169084428
< SCF= 5 NormRD= 18.314514342047 Uele= -14458.084957833029
< SCF= 6 NormRD= 29.568895957642 Uele= -14478.462542780569
< SCF= 7 NormRD= 29.827277135498 Uele= -14472.227444182059
< SCF= 8 NormRD= 15.055505487042 Uele= -14470.769290703989
< SCF= 9 NormRD= 13.551438086402 Uele= -14477.798648786273
< SCF= 10 NormRD= 13.319922100264 Uele= -14505.020614165971
in my run it looks like this:
> SCF= 1 NormRD= 1.000000000000 Uele= -14410.984428088019
> SCF= 2 NormRD= 46.972610737327 Uele= -14384.783755118091
> SCF= 3 NormRD= 46.120476790921 Uele= -14388.407013505619
> SCF= 4 NormRD= 31.180232852703 Uele= -14488.805326446905
> SCF= 5 NormRD= 37.728514788806 Uele= -14430.701463433677
> SCF= 6 NormRD= 18.517573632143 Uele= -14485.092445587958
> SCF= 7 NormRD= 23.911202727685 Uele= -14504.057753343974
> SCF= 8 NormRD= 19.011651841828 Uele= -14504.949482041782
> SCF= 9 NormRD= 51.590341572725 Uele= -14515.371205950338
> SCF= 10 NormRD= 18.236936636829 Uele= -14509.170692340536
Any ideas? I don't understand why there is so big difference between the first and second step, when the scf.Init.Mixing.Weight is 0.03 for both my and your setup.
I mean, the only difference is "scf.Max.Mixing.Weight 0.30" but that should not play a role in the first mixing?
|
| Re: Absolute core electron binding energies with surface slab ( No.11 ) |
- Date: 2021/06/10 22:38
- Name: T. Ozaki
- Hi,
This is not the issue of "scf.Max.Mixing.Weight 0.30", but may be a computational environment issue.
Have you successfully reproduced results shown in the manual and OpenMX website on your platform?
Regards,
TO
|
| Re: Absolute core electron binding energies with surface slab ( No.12 ) |
- Date: 2021/06/10 23:02
- Name: Pavel Ondracka <pavel.ondracka@email.cz>
- I did reproduced the TiC results some time ago, but not recently. I'll recheck to see if everything is OK and report back.
I also wanted to say that I really appreciate all the help I'm getting. Thank you very much.
|
| Re: Absolute core electron binding energies with surface slab ( No.13 ) |
- Date: 2021/06/12 18:09
- Name: Pavel Ondracka <pavel.ondracka@email.cz>
- All the binding energy testcases (C2H2, TiC, Si) I've tried are working fine, and also openmx -runtest shows no issues. So this must be something more subtle and really specific to my case unfortunately :-(
|
| Re: Absolute core electron binding energies with surface slab ( No.14 ) |
- Date: 2021/06/15 03:56
- Name: Pavel Ondracka <pavel.ondracka@email.cz>
- I would be be grateful for some further ideas how to track down this possible "environment" issue. Do I understand it correctly that by that you mean potential bug in compiler, libraries, or just a bad setup on my side, e.g., sch as bad compiler flags? What would be a reasonable course of action to pinpoint this down? Try a different compiler (intel vs gcc)? different libraries (mkl vs openBLAS)? Different MPI? Compile with less aggressive flags, i.e. without optimizations and no architecture specific optimization?
|
| Re: Absolute core electron binding energies with surface slab ( No.15 ) |
- Date: 2021/06/17 09:34
- Name: T. Ozaki
- Hi,
> Do I understand it correctly that by that you mean potential bug in compiler, libraries, or
> just a bad setup on my side, e.g., sch as bad compiler flags?
Yes, this is what I meant.
If your problem is actually caused by the issue, it might be difficult to fix the problem without tracing
which part of codes behaves erratically on your computational environment.
The trial and error approach that libraries and compiler options are changed may work, but it will be a hard and tedious task.
I tried to reproduce the erractic behaviour on my computational environments, but my trials were all normal.
Regards,
TO
|
| Re: Absolute core electron binding energies with surface slab ( No.16 ) |
- Date: 2021/06/22 01:51
- Name: Pavel Ondracka <pavel.ondracka@email.cz>
- I believe I figured it out. It is not an environment problem but rather a problem with the restart files (it was already mentioned in comment number 4 and 5 however from there it was not clear that then naming is not just a recommendation but a hard requirement).
In short, running a initial state with some system.name and later running the final state with the same name in the same directory (or in a new directory and copying the *_rst directory from the initial state there) leads to issues and the bad energies.
Using another system name and the scf.restart.filename to specify the restart files makes it work fine. I would appreciate some brief explanation what is going on (is this a bug or a feature)?
|
| Re: Absolute core electron binding energies with surface slab ( No.17 ) |
- Date: 2021/06/23 18:09
- Name: T. Ozaki
- Hi,
I did the same calculation, but couldn't reproduce the issue. My calculation was normal.
During the SCF calculation of the final state with the same system name, part of the restart files
stored in the *_rst directory are overwritten, which might be responcible for the issue.
But it seems to be difficult to know what's really going on your environment, since I couldn't reproduce
it on my machines.
Anyway, it would be nice to hear that you can now perform the calculation normally.
Regards,
TO
|
| Re: Absolute core electron binding energies with surface slab ( No.18 ) |
- Date: 2021/06/23 19:52
- Name: Pavel Ondracka <pavel.ondracka@email.cz>
- I'm not sure, to me it just looks that the behavior for coulomb cutoff if different when the scf.restart.filename is set for the final state (versus when its not, even though the system name is the same as for the initial state so it should not need it explicitly to find the files), or maybe I'm missing something:
Input_std.c:2533
/* specify the name of restart files, default is the same as System.Name */
ret = input_string("scf.restart.filename",restart_filename,filename);
scf_coulomb_cutoff_CoreHole = 0;
if (scf_coulomb_cutoff==1 && Scf_RestartFromFile==1 && ret==1){
scf_coulomb_cutoff_CoreHole = 1;
}
I'm running some tests right now to see if using the scf.restart.filename everytime makes things better.
|
| Re: Absolute core electron binding energies with surface slab ( No.19 ) |
- Date: 2021/07/12 23:01
- Name: Pavel Ondracka <pavel.ondracka@email.cz>
- I confirm it works now when the "scf.restart.filename" keyword is used properly. I still have some convergence problems with the core-hole calculations, but I'll open a new thread about that.
|
This thread is locked.Only browsing is available.
Absolute core electron binding energies with surface slab