[Wien] RAM usage for large k-list of a big slab

[pluto via Wien]

Dear All,

I would appreciate if you could comment on the RAM use during the band 
calculation.


I attach a graph of RAM use over several hours (this is now on i9 14900k 
with approx. 110 GB of RAM). This is during the calculation of 
51x51=2601 k-points for a very large slab (60 non-equivalent atoms). 
This is running x lapw1 -band -up -p with 4x localhost, and without omp:


Wed Jun  5 01:25:27 PM CEST 2024> (x) lapw1 -band -up -p

You can see that at some point swap activates, then actually after a 
some time one of the localhost runs crashes.


Is the behavior normal? Can something be changed by adjusting some 
settings? Possible problem with the WIEN2k compilation or with this 
particular calculation?


Best,
Lukasz___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] RAM use during band structure calculation

[pluto via Wien]

Dear All,

I am calculating 50x50 k-point mesh of a big slab. This takes several 
days on the i7 13700 desktop with 128 GB of RAM (would be faster on the 
cluster, of course).


During the lapw1 step the RAM use increases, as indicated in top or 
htop, from something like 4GB per process into something like 30GB per 
process (I run 4x k-paralell with additional OMP=2). Info from top is 
pasted below.


Is this normal? I would assume k-points are calculated one after the 
other, so the RAM use should not change.


Best,
Lukasz



Tasks: 524 total,   4 running, 520 sleeping,   0 stopped,   0 zombie
%Cpu(s): 14.0 us,  0.1 sy,  0.0 ni, 85.7 id,  0.1 wa,  0.0 hi,  0.0 si,  
0.0 st
MiB Mem : 128044.0 total,   1229.5 free, 106096.5 used,  22624.1 
buff/cache
MiB Swap:  32088.0 total,  0.1 free,  32087.9 used.  21947.6 avail 
Mem


PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ 
COMMAND
1081393 lplucin   20   0   42.4g  31.9g   9852 R 100.0  25.5   4036:02 
lapw1
1081437 lplucin   20   0   42.3g  31.9g  10824 R  99.7  25.5   4044:16 
lapw1
1081439 lplucin   20   0   42.2g  30.4g  10076 R  99.7  24.3   4022:12 
lapw1




___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] Wannier

[pluto via Wien]

Dear Gerhard, deal All,

Thank you for the answer.

Yes, this is indeed quite obvious with 3/2 and 1/2 etc. Now I see that 
the difference in occupation inside the sphere comes from slightly 
different radial wave functions for 3/2 and 1/2.


Is there a "right way" to deal with the symbol size when plotting the 
fat bands?


Best,
Lukasz




On 2024-04-09 22:28, Fecher, Gerhard wrote:

did you see the occupancies, then you should know whether the orbital
with or without star (*) belongs to the spin-orbit split  j=l+1/2 and
j=l-1/2 orbitals
p_1/2 p_3/2
d_3/2 d_5/2
f 
but it is also clear from the energies, isn't it.

Ciao
Gerhard

DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
"I think the problem, to be quite honest with you,
is that you have never actually known what the question is."


Dr. Gerhard H. Fecher
Institut of Physics
Johannes Gutenberg - University
55099 Mainz

Von: Wien [wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von
pluto via Wien [wien@zeus.theochem.tuwien.ac.at]
Gesendet: Dienstag, 9. April 2024 16:41
An: A Mailing list for WIEN2k users
Cc: pluto
Betreff: Re: [Wien] Wannier

Dear Prof. Blaha, dear All,

I would like to come back to the issue of the charge inside the sphere.
Our particular case is PtTe2, but it is general. Calculation are
spin-polarized with SOC, all atoms were disconnected/split (so I have
Pt, Te1, and Te2 atoms to make sure I can check all spin reversals on
different atoms etc).

RMTs are 2.5 for Pt and 2.48 for Te. Relevant parts of the 
case.outputst

are below. Obviously, Pt 5d and Te 5p are the most relevant, their
charges inside the sphere are approx. 0.85 and 0.5.

To avoid guessing, I would appreciate an explanation of the different
columns in case.outputst. What are the orbitals with the stars?

I am getting partial densities by using the qtl program, typically with
real-orbitals or Ylm basis.

For plotting fat bands, should I divide the numbers from case.qtlup/dn
by the charge inside the sphere?

Best,
Lukasz








Pt
   E-up(Ry)  E-dn(Ry)   Occupancy   q/sphere  core-state
   1S   -5756.006478  -5756.005274  1.00  1.001.  T
   2S   -1010.356841  -1010.352378  1.00  1.001.  T
   2P*   -968.214397   -968.211103  1.00  1.001.  T
   2P-841.118352   -841.114494  2.00  2.001.  T
   3S-237.291552   -237.289470  1.00  1.001.  T
   3P*   -218.410048   -218.407658  1.00  1.001.  T
   3P-190.470613   -190.468370  2.00  2.001.  T
   3D*   -159.097230   -159.093734  2.00  2.001.  T
   3D-153.076620   -153.073194  3.00  3.001.  T
   4S -50.981008-50.976044  1.00  1.001.  T
   4P*-42.975137-42.970052  1.00  1.001.  T
   4P -36.321439-36.316745  2.00  2.001.  T
   4D*-23.227719-23.30  2.00  2.001.  T
   4D -21.990710-21.985156  3.00  3.001.  T
   5S  -7.469817 -7.438889  1.00  1.000.9996  T
   5P* -4.923501 -4.887281  1.00  1.000.9982  F
   5P  -3.830395 -3.787722  2.00  2.000.9950  F
   4F* -5.269117 -5.261410  3.00  3.001.  F
   4F  -5.015410 -5.007479  4.00  4.001.  F
   5D* -0.535208 -0.471416  2.00  2.000.8798  F
   5D  -0.438844 -0.372982  3.00  2.000.8505  F
   6S  -0.447897 -0.372441  1.00  0.000.4004  F

Te
   E-up(Ry)  E-dn(Ry)   Occupancy   q/sphere  core-state
   1S   -2323.039164  -2323.035820  1.00  1.001.  T
   2S-356.100549   -356.099048  1.00  1.001.  T
   2P*   -333.625439   -333.622392  1.00  1.001.  T
   2P-313.450684   -313.447864  2.00  2.001.  T
   3S -70.851197-70.848181  1.00  1.001.  T
   3P*-61.613361-61.609911  1.00  1.001.  T
   3P -57.853192-57.849769  2.00  2.001.  T
   3D*-41.564608-41.561402  2.00  2.001.  T
   3D -40.778403-40.775171  3.00  3.001.  T
   4S -12.052589-12.045197  1.00  1.001.  T
   4P* -8.878596 -8.871057  1.00  1.000.  T
   4P  -8.164923 -8.157381  2.00  2.000.  T
   4D* -3.107354 -3.094692  2.00  2.000.9965  F
   4D  -2.999823 -2.986687  3.00  3.000.9961  F
   5S  -1.135690 -1.047498  1.00  1.000.7392  F
   5P* -0.508181 -0.415232  1.00  1.000.5192  F
   5P  -0.450261 -0.357641  2.00  0.000.4739  F






On 2024-02-17 10:43, Peter Blaha wrote:

Hi,

Yes, for sure you can forget the "Blm" and most important are the
"Alm".

There are 2 problems:

You may have some "Clm" (local orbitals), which could be dominating !
While this is probably less important for real "semicore states" as
you may not use them for PES, it might be important for something l

Re: [Wien] Wannier

[pluto via Wien]

ar Oleg, Mikhail, dear Prof. Blaha,

Thank you for the quick answers!

It seems that the Alm (related to the "u") coefficient might be what I 
need, because it refers to the "atomic-like" potential. Perhaps the 
Blm coefficient, related to the "u-dot", is "small" in most cases, 
also maybe it somehow represents the non-atomic (i.e. non-LCAO) 
correction to the electronic state inside the MT sphere? I apologize 
if calling "u" of LAPW as being "atomic" is wrong, but maybe it is not 
totally wrong in the spirit of my problem. I am fine with approximate 
numbers here, everything in the order of 80%-90% (say referring to the 
final ARPES intensity) would be fine, I think. (The Alm of different 
atoms would just control the amplitude and phase interference of the 
spherical waves photoemitted from these atoms.)


Does that way of thinking make some sense?

Perhaps it is also the case, that a very large LCAO basis can explain 
any band structure, but I think this is not the point, here the goal 
is to simplify the problem.


In this physical problem, I cannot live without the complex 
coefficients. This is easily understood in graphene, where the "dark 
corridor" of ARPES results from the k-dependent phases of the 
wave-functions on sites A and B.


Best,
Lukasz


On 2024-02-15 08:40, Peter Blaha wrote:

Hi,
I do not know too much about Wannerization and LCAO models.

However, I'd like to mention the  PES  program, which is included in 
WIEN2k.


It uses the atomic cross sections (as you mentioned), but not the
wavefunctions, but the "renormalized" partial DOS. (This will omitt
the interstital and renormalize in particular the delocalized
orbitals).

It does NOT include  phases (interference), but our experience is
quite good - although limited. Check out the PES section in the UG 
and

the corresponding paper by Bagheri

Regards

Am 15.02.2024 um 01:41 schrieb pluto via Wien:

Dear All,

I am interested to project WIEN2k band structure onto atomic 
orbitals, but getting complex amplitudes. For example, for graphene 
Dirac band (formed primarily by C 2pz) I would get two k-dependent 
complex numbers A_C2pz(k) and B_C2pz(k), where A and B are the two 
inequivalent sites, and these coefficients for other orbitals (near 
the Dirac points) would be nearly zero. Of course, for graphene I 
can write a TB model and get these numbers, but already for WSe2 
monolayer TB model has several bands (TB models for WSe2 are 
published but implementing would be time-consuming), and for a 
generic material there is often no simple TB model.


Some time ago I looked at the WIEN2k wave functions, but because of 
the way LAPW works, it is not a trivial task to project these onto 
atomic orbitals. This is due to the radial wave functions, each one 
receiving its own coefficient.


I was wondering if I can somehow get such projection automatically 
using Wien2Wannier, and later with some Wannier program. I thought 
it is good to ask before I invest any time into this.


And I would need it with spin, because I am interested with systems 
where SOC plays a role.


The reason I ask:
Simple model of photoemission can be made by assuming coherent 
addition of atomic-like photoionization, with additional k-dependent 
initial band amplitudes/phases. One can assume that radial integrals 
in photoemission matrix elements don't have special structure and 
maybe just take atomic cross sections of Yeh-Lindau. But one still 
needs these complex coefficients to allow for interference of the 
emission from different sites within the unit cell. I think for a 
relatively simple material such as WSe2 monolayer, the qualitative 
result of this might be reasonable. I am not aiming at anything 
quantitative since we have one-step-model codes for quantitative.


Any suggestion on how to do this projection (even approximately) 
within the realm of WIEN2k would be welcome.


Best,
Lukasz


PD Dr. Lukasz Plucinski
Group Leader, FZJ PGI-6
Phone: +49 2461 61 6684
https://electronic-structure.fz-juelich.de/

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at: 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] How to assign kz to slab bands?

[pluto via Wien]

Dear Prof. Blaha,

Thank you for the comment.

fold2Bloch might be exactly what I need! There are papers where it is 
mentioned in relation to ARPES.


Best,
Lukasz






On 2024-02-24 16:05, Peter Blaha wrote:

Hi,

There is no automatic tool for this.

I detected surface states by an analysis of the partial charges of the
atoms in the various layers. A surface state should have charge only
in the surface (maybe a bit in the subsurface layer).

Note, there is   fold2bloch, which does backfolding of supercells, but
I don't know what to do with the vacuum.
One could try to give him a supercell in z direction without vacuum
and still use the eigenvectors from the supercell+vacuum calculation,
but it may give complete nonsense.

Best regards
Peter Blaha

Am 23.02.2024 um 17:02 schrieb pluto via Wien:

Dear All,

Everyone who has done a slab calculation knows that it contains some 
surface states and some projected bulk bands.


These projected bulk bands are typically nearly identical to the bulk 
projected bands. If we have a 10ML slab, they will essentially look 
like cutting the bulk BZ 10 times along kz. In case of bulk bands 
obviously each cut is assigned to some kz.


Now, we can compare bulk projected bands and slab bands, and then we 
will more or less know which of the slab bands relate to which kz 
(besides the surface states that don't have kz).


Is there a simple way to automatically assign kz to the slab bands?

One solution to this problem would be to calculate something like 
, which is essentially a Fourier 
transform of the initial wave function for some energy and k_paral, 
i.e. for one eigenvalue point in the band structure. Is that kind of 
matrix element hidden somewhere in the WIEN2k output files?


Actually, this would also assign kz to the surface states, which could 
also be useful in the photoemission context.


Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] How to assign kz to slab bands?

[pluto via Wien]

Dear All,

Everyone who has done a slab calculation knows that it contains some 
surface states and some projected bulk bands.


These projected bulk bands are typically nearly identical to the bulk 
projected bands. If we have a 10ML slab, they will essentially look like 
cutting the bulk BZ 10 times along kz. In case of bulk bands obviously 
each cut is assigned to some kz.


Now, we can compare bulk projected bands and slab bands, and then we 
will more or less know which of the slab bands relate to which kz 
(besides the surface states that don't have kz).


Is there a simple way to automatically assign kz to the slab bands?

One solution to this problem would be to calculate something like 
, which is essentially a Fourier transform 
of the initial wave function for some energy and k_paral, i.e. for one 
eigenvalue point in the band structure. Is that kind of matrix element 
hidden somewhere in the WIEN2k output files?


Actually, this would also assign kz to the surface states, which could 
also be useful in the photoemission context.


Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] Wannier

[pluto via Wien]

Dear Oleg, Mikhail, dear Prof. Blaha,

Thank you for the quick answers!

It seems that the Alm (related to the "u") coefficient might be what I 
need, because it refers to the "atomic-like" potential. Perhaps the Blm 
coefficient, related to the "u-dot", is "small" in most cases, also 
maybe it somehow represents the non-atomic (i.e. non-LCAO) correction to 
the electronic state inside the MT sphere? I apologize if calling "u" of 
LAPW as being "atomic" is wrong, but maybe it is not totally wrong in 
the spirit of my problem. I am fine with approximate numbers here, 
everything in the order of 80%-90% (say referring to the final ARPES 
intensity) would be fine, I think. (The Alm of different atoms would 
just control the amplitude and phase interference of the spherical waves 
photoemitted from these atoms.)


Does that way of thinking make some sense?

Perhaps it is also the case, that a very large LCAO basis can explain 
any band structure, but I think this is not the point, here the goal is 
to simplify the problem.


In this physical problem, I cannot live without the complex 
coefficients. This is easily understood in graphene, where the "dark 
corridor" of ARPES results from the k-dependent phases of the 
wave-functions on sites A and B.


Best,
Lukasz


On 2024-02-15 08:40, Peter Blaha wrote:

Hi,
I do not know too much about Wannerization and LCAO models.

However, I'd like to mention the  PES  program, which is included in 
WIEN2k.


It uses the atomic cross sections (as you mentioned), but not the
wavefunctions, but the "renormalized" partial DOS. (This will omitt
the interstital and renormalize in particular the delocalized
orbitals).

It does NOT include  phases (interference), but our experience is
quite good - although limited. Check out the PES section in the UG and
the corresponding paper by Bagheri

Regards

Am 15.02.2024 um 01:41 schrieb pluto via Wien:

Dear All,

I am interested to project WIEN2k band structure onto atomic orbitals, 
but getting complex amplitudes. For example, for graphene Dirac band 
(formed primarily by C 2pz) I would get two k-dependent complex 
numbers A_C2pz(k) and B_C2pz(k), where A and B are the two 
inequivalent sites, and these coefficients for other orbitals (near 
the Dirac points) would be nearly zero. Of course, for graphene I can 
write a TB model and get these numbers, but already for WSe2 monolayer 
TB model has several bands (TB models for WSe2 are published but 
implementing would be time-consuming), and for a generic material 
there is often no simple TB model.


Some time ago I looked at the WIEN2k wave functions, but because of 
the way LAPW works, it is not a trivial task to project these onto 
atomic orbitals. This is due to the radial wave functions, each one 
receiving its own coefficient.


I was wondering if I can somehow get such projection automatically 
using Wien2Wannier, and later with some Wannier program. I thought it 
is good to ask before I invest any time into this.


And I would need it with spin, because I am interested with systems 
where SOC plays a role.


The reason I ask:
Simple model of photoemission can be made by assuming coherent 
addition of atomic-like photoionization, with additional k-dependent 
initial band amplitudes/phases. One can assume that radial integrals 
in photoemission matrix elements don't have special structure and 
maybe just take atomic cross sections of Yeh-Lindau. But one still 
needs these complex coefficients to allow for interference of the 
emission from different sites within the unit cell. I think for a 
relatively simple material such as WSe2 monolayer, the qualitative 
result of this might be reasonable. I am not aiming at anything 
quantitative since we have one-step-model codes for quantitative.


Any suggestion on how to do this projection (even approximately) 
within the realm of WIEN2k would be welcome.


Best,
Lukasz


PD Dr. Lukasz Plucinski
Group Leader, FZJ PGI-6
Phone: +49 2461 61 6684
https://electronic-structure.fz-juelich.de/

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] Wannier

[pluto via Wien]

Dear All,

I am interested to project WIEN2k band structure onto atomic orbitals, 
but getting complex amplitudes. For example, for graphene Dirac band 
(formed primarily by C 2pz) I would get two k-dependent complex numbers 
A_C2pz(k) and B_C2pz(k), where A and B are the two inequivalent sites, 
and these coefficients for other orbitals (near the Dirac points) would 
be nearly zero. Of course, for graphene I can write a TB model and get 
these numbers, but already for WSe2 monolayer TB model has several bands 
(TB models for WSe2 are published but implementing would be 
time-consuming), and for a generic material there is often no simple TB 
model.


Some time ago I looked at the WIEN2k wave functions, but because of the 
way LAPW works, it is not a trivial task to project these onto atomic 
orbitals. This is due to the radial wave functions, each one receiving 
its own coefficient.


I was wondering if I can somehow get such projection automatically using 
Wien2Wannier, and later with some Wannier program. I thought it is good 
to ask before I invest any time into this.


And I would need it with spin, because I am interested with systems 
where SOC plays a role.


The reason I ask:
Simple model of photoemission can be made by assuming coherent addition 
of atomic-like photoionization, with additional k-dependent initial band 
amplitudes/phases. One can assume that radial integrals in photoemission 
matrix elements don't have special structure and maybe just take atomic 
cross sections of Yeh-Lindau. But one still needs these complex 
coefficients to allow for interference of the emission from different 
sites within the unit cell. I think for a relatively simple material 
such as WSe2 monolayer, the qualitative result of this might be 
reasonable. I am not aiming at anything quantitative since we have 
one-step-model codes for quantitative.


Any suggestion on how to do this projection (even approximately) within 
the realm of WIEN2k would be welcome.


Best,
Lukasz


PD Dr. Lukasz Plucinski
Group Leader, FZJ PGI-6
Phone: +49 2461 61 6684
https://electronic-structure.fz-juelich.de/

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] Atomic muffin tin potential output

[pluto via Wien]

Dear All,

An electron scattering program I am testing can take atomic muffin-tin 
potential as an input.


Is there a convenient way to output such muffin tin potentials from 
WIEN2k?


If not, then I would appreciate if you could advise on how to generate 
such muffin tin potentials conveniently.


Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] Speed of cluster nodes

[pluto via Wien]

Dear Prof. Blaha,

Reducing the energy window in case.inso seems to work, but there are 
some minor issues. I would like to clarify them.


Normally I run the sequence:

x lapw1 -band -up -p
x lapw1 -band -dn -p
x lapwso -up -p
x qtl -up -p -band -so
x qtl -dn -p -band -so

When I limit the range a lot in case.inso before starting this sequence, 
I don't have Fermi energy in the case.scf2up/dn (I paste such "bad" file 
below). This then leads to an error when running "x qtl".


It seems there is no error when first running "x lapw1 up/dn" and "x 
lapwso" with the default case.inso, then limiting the range in 
case.inso, and then re-running only "x lapwso".


Maybe you could comment what would be the correct sequence here.

Best,
Lukasz

PS: "x qtl" needs case.in1c for running correctly. So, if that file does 
not exist then I simply make a copy of the case.in1. Is that OK?






   TEMP.-SMEARING WITH0.00200 Ry
  -S / Kb   =  -6.57973595
  -(T*S)/2  =  -0.00328987
  Chem Pot  = 
 Bandranges (emin - emax) and occupancy:
Energy to separate low and high energystates:0.39949


:NOE  : NUMBER OF ELECTRONS  = 1440.000

:FER  : F E R M I - ENERGY(FERMI-SM.)= **
:GMA  : POTENTIAL AND CHARGE CUT-OFF  16.00 Ry**.5








On 2023-11-11 18:20, Peter Blaha wrote:

For your problem, you just need to reduce the Energy window in
case.inso when you do the fine k-mesh (no scf with this k-mesh).
Make sure, your emin does not cut bands, but falls in a "gap".

Usually, all k-points take the same time (within 10 % or so).
It looks more as if one node is (temporarely) overloaded or has
network (disk) problems.
Try to check it by logging into this node and use eg. "top".


Am 10.11.2023 um 18:53 schrieb pluto via Wien:

Dear Prof. Blaha, dear All,

Thank you for you comment. When changing numbers as you suggested the 
convergence over few cycles didn't look very good. So I decided to 
redo the calculation with init_lapw -prec 1 -ecut 0.999, I think this 
is safer and I hope the files will be smaller. Once this is done, I 
will try to reduce emax in case.inso.


The origin of the problem is that I would like to make a kx-ky mesh 
for the slab, this means maybe 2000-3000 kpoints to see bands as 
surfaces nicely. Then the output files become very large, and case.qtl 
files are large too (I typically do a SOC and FM calculation). One can 
limit the energy range in case.inq to e.g. from -1 to 1, but this 
sometimes (for unknown reasons) leads to some counting issues of the 
bands, i.e. different k-points have different bands order. This might 
be related to the lower energy cutting though a band, but some time 
ago I tried different ranges in case.inq and it was not very helpful 
(but I need to try more). Anyway, not a big deal, in the end this can 
be sorted out in many ways. In general most of the time I only need 
bands from say -10 to 10 eV around the Fermi level, so in general it 
is good to learn how to calculate only that, perhaps increasing the 
calculation speed and reducing the output file sizes.


Another question: I often run on the older cluster. All nodes should 
be the same and I distribute k-points uniformly (e.g. 8 k-points per 
node). I noticed that sometimes some nodes are calculating much slower 
(e.g. lapw1 or lapwso) than other nodes. Is that normal? I would 
expect maybe small fluctuations due to the particular CPU cooling 
efficiency etc., but nothing dramatic. Or perhaps sometimes some 
k-points need more time?


Best,
Lukasz


On 2023-11-07 18:42, Peter Blaha wrote:

I'm not quite sure what you mean.

restore your saved calculation and:
i)  Reduce emax in case.inso
This reduces the size of case.vectorso, but has no influence on the
scf. (One iteration is enough).
ii) reduce Ecut in case.in1.  However, this will make your spinorbit
calculation much less accurate. You need to run the scf, but it 
should

converge quicker .

Am 07.11.2023 um 18:26 schrieb pluto via Wien:

Dear All,

I have a larger FM-SOC calculation converged (and saved) with the 
default Ecut.


I would like to converge with smaller Ecut (say 1 Ry), to have the 
output files smaller.


Is there a good way to do this, using the converged one as a 
starting point, to avoid the lenghty convergence?


Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at: 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

__

[Wien] Speed of cluster nodes

[pluto via Wien]

Dear Prof. Blaha, dear All,

Thank you for you comment. When changing numbers as you suggested the 
convergence over few cycles didn't look very good. So I decided to redo 
the calculation with init_lapw -prec 1 -ecut 0.999, I think this is 
safer and I hope the files will be smaller. Once this is done, I will 
try to reduce emax in case.inso.


The origin of the problem is that I would like to make a kx-ky mesh for 
the slab, this means maybe 2000-3000 kpoints to see bands as surfaces 
nicely. Then the output files become very large, and case.qtl files are 
large too (I typically do a SOC and FM calculation). One can limit the 
energy range in case.inq to e.g. from -1 to 1, but this sometimes (for 
unknown reasons) leads to some counting issues of the bands, i.e. 
different k-points have different bands order. This might be related to 
the lower energy cutting though a band, but some time ago I tried 
different ranges in case.inq and it was not very helpful (but I need to 
try more). Anyway, not a big deal, in the end this can be sorted out in 
many ways. In general most of the time I only need bands from say -10 to 
10 eV around the Fermi level, so in general it is good to learn how to 
calculate only that, perhaps increasing the calculation speed and 
reducing the output file sizes.


Another question: I often run on the older cluster. All nodes should be 
the same and I distribute k-points uniformly (e.g. 8 k-points per node). 
I noticed that sometimes some nodes are calculating much slower (e.g. 
lapw1 or lapwso) than other nodes. Is that normal? I would expect maybe 
small fluctuations due to the particular CPU cooling efficiency etc., 
but nothing dramatic. Or perhaps sometimes some k-points need more time?


Best,
Lukasz


On 2023-11-07 18:42, Peter Blaha wrote:

I'm not quite sure what you mean.

restore your saved calculation and:
i)  Reduce emax in case.inso
This reduces the size of case.vectorso, but has no influence on the
scf. (One iteration is enough).
ii) reduce Ecut in case.in1.  However, this will make your spinorbit
calculation much less accurate. You need to run the scf, but it should
converge quicker .

Am 07.11.2023 um 18:26 schrieb pluto via Wien:

Dear All,

I have a larger FM-SOC calculation converged (and saved) with the 
default Ecut.


I would like to converge with smaller Ecut (say 1 Ry), to have the 
output files smaller.


Is there a good way to do this, using the converged one as a starting 
point, to avoid the lenghty convergence?


Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] Re-converge with smaller Ecut

[pluto via Wien]

Dear All,

I have a larger FM-SOC calculation converged (and saved) with the 
default Ecut.


I would like to converge with smaller Ecut (say 1 Ry), to have the 
output files smaller.


Is there a good way to do this, using the converged one as a starting 
point, to avoid the lenghty convergence?


Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] ** testerror: Error in Parallel LAPW

[pluto via Wien]

Dear Miro,

On my cluster it works by a command

salloc -p cluster_name -N6 sleep infinity &

This particular command allocates 6 nodes. You can find which ones by 
squeue command. Then passworless to these nodes is allowed in my 
cluster. Then in .machines I include the names of these nodes and things 
work.


But there is a big chance that this is blocked in your cluster, you need 
to ask your administrator.


I think srun is the required command within the slurm shell script. You 
should get some example shell scripts from your administrator or 
colleagues who use the cluster.


As I mentioned in my earlier email, Prof. Blaha provides workarounds for 
slurm. If simple ways are blocked, you will just need to implement these 
workarounds. It might not be easy, but setting up cluster calculations 
is not supposed to be easy.


Best,
Lukasz




On 2023-06-21 22:58, Ilias Miroslav, doc. RNDr., PhD. wrote:

Dear all,

 ad:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg22588.html
[1]

 " In order to use multiple nodes, you need to be able to do
passwordless ssh to the allocated nodes (or any other command
substituting ssh). "

 According to our cluster admin, one  can use (maybe) 'srun' to
allocate and connect to a batch node.
https://hpc.gsi.de/virgo/slurm/resource_allocation.html [2]

 Would  it possible to use  "srun" within Wien2k scripts to run
parallel jobs please ?  We are using common disk space on that
cluster.

 Best, Miro


Links:
--
[1] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg22588.html

[2] https://hpc.gsi.de/virgo/slurm/resource_allocation.html
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] ** testerror: Error in Parallel LAPW

[pluto via Wien]

Dear Miro,

It is hard to give your a meaningful answer with little info, but I will 
try my best guess because I needed to set this up recently. I assume 
that you want to use k-parallel and you don't have mpi.


With a serial job you automatically run on a single node. Single node is 
a physical computer with a physical CPU, but typically with 4 memory 
channels to it can run 8 jobs in parallel.


With k-parallel you need to define nodes on which k-points are 
calculated. With slurm, maybe things will work if you create 8 
"localhost" lines in .machines file, because this will still run on a 
single node that is assigned automatically. But things probably won't 
work if you create lines such as "node001", "node002" etc (depending on 
the names of the nodes in your cluster). And to take an advantage of the 
cluster you need to use as many nodes as possible.


Now the problem is, that k-parallel works assuming you can ssh to every 
node without a password. This is typically forbidden in the slurm 
environment. Prof. Blaha provides workarounds, but to me their 
implementation seems complicated (I not an expert): 
http://www.wien2k.at/reg_user/faq/pbs.html


I am using an older cluster where it is possible to allocate nodes, and 
with this allocation comes automatically passwordless ssh to these 
nodes. Then the slurm workarounds are not needed. Maybe you can talk to 
your administrator if this is possible in your cluster, because I think 
typically this is blocked.


Best,
Lukasz





On 2023-06-20 10:18, Ilias Miroslav, doc. RNDr., PhD. wrote:

Hello,

 I am able to run serial SCF via SLURM


https://github.com/miroi/open-collection/blob/master/theoretical_chemistry/software/wien2k/runs/LvO2_on_small_quartz/wien2k/LvO2onQg/virgo_slurm_wien2kgnupar_fromdstart.01


 but when trying parallel

https://github.com/miroi/open-collection/blob/master/theoretical_chemistry/software/wien2k/runs/LvO2_on_small_quartz/wien2k/LvO2onQg/virgo_slurm_wien2kgnupar_fromdstart.02


 I get lapw2.error

 'LAPW2' - can't open unit: 30

'LAPW2' -filename: LvO2onQg.energy_1

**  testerror: Error in Parallel LAPW2

 The file "LvO2onQg.energy" is correct in serial mode.

 Seems that LvO2onQg.energy_1 file is not produces in parallel run ?

 All files are
https://github.com/miroi/open-collection/tree/master/theoretical_chemistry/software/wien2k/runs/LvO2_on_small_quartz/wien2k/LvO2onQg
[1]

 Best,

 Miro


Links:
--
[1]
https://github.com/miroi/open-collection/tree/master/theoretical_chemistry/software/wien2k/runs/LvO2_on_small_quartz/wien2k/LvO2onQg
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] Strategy for a large slab with SP and SOC

[pluto via Wien]

Dear Prof. Blaha, Marks,

Thank you for your comments, they solved my problem immediately!

It "magically" works with init_lapw -prec 1 -ecut 0.999 :-)

Why -ecut 0.999 and not -ecut 1? Is the consequence of this only in not 
having core-levels (I don't need them in this case)?


I converged, and then continued with a larger klist, but the results are 
nearly identical.


WTe2 that I am calculating is semimetallic, therefore I used -prec 1 and 
not -prec 1n. Also, I am replicating what has been already calculated by 
several groups (for the purpose of a more detailed spin/orbital 
character study), therefore I know what the result for the band energies 
should be.


Best,
Lukasz




On 2023-06-17 08:47, Laurence Marks wrote:

In addition to what Peter said, pay careful attention to how you setup
the slab calculation. WTe2 has a band gap of 1.0 eV, and it may be
less with PBE. I suggest checking your bulk band gap first.

With a small gap surface, TEMPS is needed and getting the positions
right (-min) and a valence neutral surface will matter. You will need
to converge density and positions without soc. If you don't setup the
surface right GIGO and if will be horribly unstable. (STIFF in
case.inm may help.) With GIGO the physics is wrong so your
calculations will be meaningless.

---
Professor Laurence Marks (Laurie)
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu [1]
"Research is to see what everybody else has seen, and to think what
nobody else has thought" Albert Szent-Györgyi

On Sat, Jun 17, 2023, 09:01 Peter Blaha 
wrote:


Your 4 points are not really recommended in the first place.

If it is a scf convergence problem (which I doubt):  grep:DIS
case.scf
. Does it look like divergence ?

You need to find which eigenvalue causes the ghostband, from which
atom
and angular momentum.

See *scf2* and *output2* files.

Once you know this, look into case.scf1 to see how the LOs and
energy
parameters for this state are set and you probably have to modyfy
case.in1(c).

PS: Use  init_lapw -prec 1n   at the beginning, maybe with -ecut
0.999 .

PS: I would NOT include HDLOs, if I had ghostbands. Mixing with
PRATT
helps only in very few cases, not really recommended for "normal"
calculations.

PPS: I hope you use   runsp_c_lapw   for something like WTe2 ?

Am 17.06.2023 um 00:28 schrieb pluto via Wien:

Dear Prof. Blaha, dear All,

Thank you for the comment on slab strategy, this helps a lot.

I have more specific question: for a large WTe2 slab (60 atoms),

which

is a material of low-symmetry that has a polarity also in the
out-of-plane direction, I am getting ghostbands in lapw2 after few



iterations. What is a good strategy to fix this?

I was thinking of:

1. init_lapw -hdlo
2. Low mixing (like 0.05) with PRATT
3. Decrease RMT (from first tests, with RMT 2.5 ghostbands seem to



appear after around 3 iterations, with 2.2 after many iterations)
4. Increase RKmax

3 and 4 are probably computationally expensive...

I did several tests without SOC, I was typically using something

like:


init_lapw -sp -b -numk 100 -hdlo -fermit 0.002

Maybe other settings are critical?

Bulk calculation converges very easily (first without and then

with

SOC) with default settings like

init_lapw -sp -b -numk 2000

bulk bands look like the literature, and are practically the same

with

RMT 2.2 and RMT 2.5.

Best,
Lukasz




On 2023-06-16 16:45, Peter Blaha wrote:

No,this is not a good strategy.

From a converged non-spin-polarized calculation you cannot come
(easily) to a spin-polarized solution.

So   1) is only good if you want to quote how much more stable a

SP

solution is compared to a non-SP.

2 + 3 is a good practice. You gain insight how large are the

changes

and on what atoms due to SO coupling.



In terms of efficiency for large cases, I'd in particular

preconverge

with a course k-mesh and later on refine.

---

Every runsp cycle starts with a case.clmsum/up/dn file.

These files can come from an initialization, but of course also

from

any prior scf calculation (eg. with lower k-mesh or without SO).

Of

course, a restore_lapw ... gives you all files necessary to run
another scf cycle.

-NI would keep old broyden files, but after a "save_lapw" they

are

gone anyway.  -NI is useful if you want to continue a scf,

because eg.

the first runsp stopped after 40 cycles and did not reach

convergence

yet.

Am 16.06.2023 um 10:44 schrieb pluto via Wien:

Dear All,

I just would like to confirm the step-by-step convergence

strategy

for the large slab with SP and SOC (it refers in general to
spin-momentum locked non-magnetic TMDC, but can be any other

material).


Is the following correct:

1. Converge without SP and without SOC, and save_lapw e.g. as
CONV_NO_SP_NO_SOC so it can be used in another directory or on
another computer for the next steps
2. Use this

Re: [Wien] Strategy for a large slab with SP and SOC

[pluto via Wien]

Dear Prof. Blaha, dear All,

Thank you for the comment on slab strategy, this helps a lot.

I have more specific question: for a large WTe2 slab (60 atoms), which 
is a material of low-symmetry that has a polarity also in the 
out-of-plane direction, I am getting ghostbands in lapw2 after few 
iterations. What is a good strategy to fix this?


I was thinking of:

1. init_lapw -hdlo
2. Low mixing (like 0.05) with PRATT
3. Decrease RMT (from first tests, with RMT 2.5 ghostbands seem to 
appear after around 3 iterations, with 2.2 after many iterations)

4. Increase RKmax

3 and 4 are probably computationally expensive...

I did several tests without SOC, I was typically using something like:

init_lapw -sp -b -numk 100 -hdlo -fermit 0.002

Maybe other settings are critical?

Bulk calculation converges very easily (first without and then with SOC) 
with default settings like


init_lapw -sp -b -numk 2000

bulk bands look like the literature, and are practically the same with 
RMT 2.2 and RMT 2.5.


Best,
Lukasz




On 2023-06-16 16:45, Peter Blaha wrote:

No,this is not a good strategy.

From a converged non-spin-polarized calculation you cannot come
(easily) to a spin-polarized solution.

So   1) is only good if you want to quote how much more stable a SP
solution is compared to a non-SP.

2 + 3 is a good practice. You gain insight how large are the changes
and on what atoms due to SO coupling.



In terms of efficiency for large cases, I'd in particular preconverge
with a course k-mesh and later on refine.

---

Every runsp cycle starts with a case.clmsum/up/dn file.

These files can come from an initialization, but of course also from
any prior scf calculation (eg. with lower k-mesh or without SO). Of
course, a restore_lapw ... gives you all files necessary to run
another scf cycle.

-NI would keep old broyden files, but after a "save_lapw" they are
gone anyway.  -NI is useful if you want to continue a scf, because eg.
the first runsp stopped after 40 cycles and did not reach convergence
yet.

Am 16.06.2023 um 10:44 schrieb pluto via Wien:

Dear All,

I just would like to confirm the step-by-step convergence strategy for 
the large slab with SP and SOC (it refers in general to spin-momentum 
locked non-magnetic TMDC, but can be any other material).


Is the following correct:

1. Converge without SP and without SOC, and save_lapw e.g. as 
CONV_NO_SP_NO_SOC so it can be used in another directory or on another 
computer for the next steps
2. Use this as a starting point to converge with SP, and save_lapw as 
CONV_W_SP_NO_SOC (one can also restore_lapw in another directory and 
start there)
3. Use this as a starting point to converge with SP and with SOC (and 
save_lapw to have it for the future)


I often start with step 3 right away, but I think for a really large 
system this might be really inefficient.


How does the program know to use the starting density from the 
previous step?
Does restore_lapw creates the necessary files when I transfer to the 
new directory?

Is -NI or some other setting in run_lapw important here?

At the moment I am using an older cluster with many cores and use 
k-parallel. Still didn't manage with MPI, but maybe it is not needed 
for what I want because my klist file is typically 50-80 k-points, 
depending on the symmetry of the system. I use the QTL program quite a 
lot so having it parallellized would sometimes speed the things up a 
bit for me.


Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at: 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] Strategy for a large slab with SP and SOC

[pluto via Wien]

Dear All,

I just would like to confirm the step-by-step convergence strategy for 
the large slab with SP and SOC (it refers in general to spin-momentum 
locked non-magnetic TMDC, but can be any other material).


Is the following correct:

1. Converge without SP and without SOC, and save_lapw e.g. as 
CONV_NO_SP_NO_SOC so it can be used in another directory or on another 
computer for the next steps
2. Use this as a starting point to converge with SP, and save_lapw as 
CONV_W_SP_NO_SOC (one can also restore_lapw in another directory and 
start there)
3. Use this as a starting point to converge with SP and with SOC (and 
save_lapw to have it for the future)


I often start with step 3 right away, but I think for a really large 
system this might be really inefficient.


How does the program know to use the starting density from the previous 
step?
Does restore_lapw creates the necessary files when I transfer to the new 
directory?

Is -NI or some other setting in run_lapw important here?

At the moment I am using an older cluster with many cores and use 
k-parallel. Still didn't manage with MPI, but maybe it is not needed for 
what I want because my klist file is typically 50-80 k-points, depending 
on the symmetry of the system. I use the QTL program quite a lot so 
having it parallellized would sometimes speed the things up a bit for 
me.


Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] lapw1 vs lapwso speed

[pluto via Wien]

Dear All,

Thank you for the answers.

Just to clarify, this questions was regarding a large case.klist_band 
file. For the scf run, I always use much smaller case.klist, especially 
for a large slab that has no out-of-plane dispersion.


Best,
Lukasz





On 2023-06-11 21:47, Peter Blaha wrote:

This is usually not true, except when EMAX is set to 100 Ry or so.

We use for lapwso  as basisset the lapw1 eigenstates, thus the
dimension of the lapwso eigenvalue problem is only  2 * NE, where NE
is typically (depending on EMAX) 20-30% of NMAT of lapw1.

Am 11.06.2023 um 16:33 schrieb Yundi Quan via Wien:
The matrix that lapw1 -up solves is the spin up part of the 
Hamiltonian and it should be much smaller than the matrix that lapwso 
solves.


On Sunday, June 11, 2023, Peter Blaha <mailto:peter.bl...@tuwien.ac.at>> wrote:


The speed of lapwso depends on EMAX in case.in1, which limits the
number of eigenvalues calculated in lapw1 and used as basis for 
lapwso.


With EMAX=5.0 the speed of lapw1 and lapwso is usually similar.
With larger emax lapwso may take much more time.

Am 11.06.2023 um 12:36 schrieb pluto via Wien:

Dear All,

When calculating bands for a large slab I have following 
sequence:


Sun May 14 12:33:03 PM CEST 2023> (x) lapw1 -band -up -p
Sun May 14 02:25:26 PM CEST 2023> (x) lapw1 -band -dn -p
Sun May 14 04:17:22 PM CEST 2023> (x) lapwso -up -p
Mon May 15 01:30:05 AM CEST 2023> (x) qtl -up -p -band -so
Mon May 15 01:30:05 AM CEST 2023> (x) lapw2 -p -fermi -so -up
Mon May 15 01:51:51 AM CEST 2023> (x) qtl -dn -p -band -so
Mon May 15 01:51:51 AM CEST 2023> (x) lapw2 -p -fermi -so -dn

As you can see lapwso takes much longer than lapw1 (approx. 9h
vs 2h). Is this normal for band calculations?

I have 128 GB of RAM in this computer, so this is not a RAM
issue. Here is what top shows for the lapwso calculation (I 
have
4 parallel localhost processes in .machines, OMP=2 and no 
mpi):


Tasks: 505 total,   2 running, 503 sleeping,   0 stopped,   0 
zombie
%Cpu(s): 24.0 us,  0.2 sy,  0.0 ni, 75.7 id,  0.0 wa,  0.1 hi, 
0.0 si, 0.0 st
MiB Mem : 128047.1 total,   1845.8 free,  16809.0 used, 
58.6

buff/cache
MiB Swap:  32088.0 total,  31471.5 free,    616.5 used. 
111238.1

avail Mem

  PID USER  PR  NI    VIRT    RES    SHR S  %CPU   
  %MEM TIME+ COMMAND
1336417 lplucin   20   0 6417856   4.8g  15840 R 199.3   3.8   
   1294:13 lapwso
1336392 lplucin   20   0 2848204   2.3g  15880 S 146.8   1.9   
   1295:30 lapwso
1336391 lplucin   20   0 2848188   2.4g  15916 S 130.6   1.9   
   1304:23 lapwso
1336396 lplucin   20   0 2848060   2.3g  15816 S  99.7   1.9   
   1288:06 lapwso


.machines file:

omp_global:8
omp_lapw1:2
omp_lapw2:2
omp_lapwso:2
1:localhost
1:localhost
1:localhost
1:localhost
granularity:1

Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
<mailto:Wien@zeus.theochem.tuwien.ac.at>
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
<http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien>
SEARCH the MAILING-LIST at:

http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html 
<http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html>



-- 
--

Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.bl...@tuwien.ac.at <mailto:peter.bl...@tuwien.ac.at>  
 WIEN2k: http://www.wien2k.at <http://www.wien2k.at>

WWW: http://www.imc.tuwien.ac.at <http://www.imc.tuwien.ac.at>

-

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at 
<mailto:Wien@zeus.theochem.tuwien.ac.at>

http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
<http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien>
SEARCH the MAILING-LIST at:

http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html 
<http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html>



___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.a

[Wien] lapw1 vs lapwso speed

[pluto via Wien]

Dear All,

When calculating bands for a large slab I have following sequence:

Sun May 14 12:33:03 PM CEST 2023> (x) lapw1 -band -up -p
Sun May 14 02:25:26 PM CEST 2023> (x) lapw1 -band -dn -p
Sun May 14 04:17:22 PM CEST 2023> (x) lapwso -up -p
Mon May 15 01:30:05 AM CEST 2023> (x) qtl -up -p -band -so
Mon May 15 01:30:05 AM CEST 2023> (x) lapw2 -p -fermi -so -up
Mon May 15 01:51:51 AM CEST 2023> (x) qtl -dn -p -band -so
Mon May 15 01:51:51 AM CEST 2023> (x) lapw2 -p -fermi -so -dn

As you can see lapwso takes much longer than lapw1 (approx. 9h vs 2h). 
Is this normal for band calculations?


I have 128 GB of RAM in this computer, so this is not a RAM issue. Here 
is what top shows for the lapwso calculation (I have 4 parallel 
localhost processes in .machines, OMP=2 and no mpi):


Tasks: 505 total,   2 running, 503 sleeping,   0 stopped,   0 zombie
%Cpu(s): 24.0 us,  0.2 sy,  0.0 ni, 75.7 id,  0.0 wa,  0.1 hi,  0.0 si,  
0.0 st
MiB Mem : 128047.1 total,   1845.8 free,  16809.0 used, 58.6 
buff/cache
MiB Swap:  32088.0 total,  31471.5 free,616.5 used. 111238.1 avail 
Mem


PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ 
COMMAND
1336417 lplucin   20   0 6417856   4.8g  15840 R 199.3   3.8   1294:13 
lapwso
1336392 lplucin   20   0 2848204   2.3g  15880 S 146.8   1.9   1295:30 
lapwso
1336391 lplucin   20   0 2848188   2.4g  15916 S 130.6   1.9   1304:23 
lapwso
1336396 lplucin   20   0 2848060   2.3g  15816 S  99.7   1.9   1288:06 
lapwso


.machines file:

omp_global:8
omp_lapw1:2
omp_lapw2:2
omp_lapwso:2
1:localhost
1:localhost
1:localhost
1:localhost
granularity:1

Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] shell script issue

[pluto via Wien]

Dear All,

This issue seems to be related to the terminal process.

I typically run the shell script from the remote terminal, and then at 
some point the terminal window from which I run it is terminated. (I 
typically use putty in Windows 10, but I don't think this is important).


When the terminal window is terminated, then the problem with the script 
happens (i.e. all remaining steps start at once).


The solution is to use tmux terminal emulator inside the terminal (just 
type tmux, and then a kind of new shell appears in the same directory as 
before). Then one simply runs the shell script within the tmux 
environment. Then one should hard close the terminal (e.g. terminate the 
putty). Then everything works fine.


There are probably more proper ways of solving this, but this one works 
for me and it is easy.


Best,
Lukasz




On 2023-04-20 15:57, Laurence Marks wrote:

As an addition to what Peter said, did you check the error files, e.g.
cat *.error?

---
Professor Laurence Marks (Laurie)
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu [1]
"Research is to see what everybody else has seen, and to think what
nobody else has thought" Albert Szent-Györgyi

On Thu, Apr 20, 2023, 08:51 Peter Blaha 
wrote:


If this is really your script, it should not happen. Your script is
course ok (although I'm not a bash specialist).

Maybe some bug in your Linux ?

alternatively, change to first line of your script to /bin/csh -f or

/bin/tcsh -f

and see what happens.

Am 20.04.2023 um 12:19 schrieb pluto via Wien:

Dear All,

I would like to calculate the sequence of programs to get the band



characters under bash:

calculate_bands.sh

#! /bin/bash
x lapw1 -band -up -p
x lapw1 -band -dn -p
x lapwso -up -p
x qtl -band -so -p -up
x qtl -band -so -p -dn

I run this from the terminal under Rocky Linux using

calculate_bands.sh &

Here is the result:

Thu Apr 20 01:03:29 AM CEST 2023> (x) lapw1 -band -up -p
Thu Apr 20 02:18:29 AM CEST 2023> (x) lapw1 -band -dn -p
Thu Apr 20 02:18:29 AM CEST 2023> (x) lapwso -up -p
Thu Apr 20 02:18:29 AM CEST 2023> (x) qtl -band -so -p -up
Thu Apr 20 02:18:29 AM CEST 2023> (x) lapw2 -p -fermi -so -up
Thu Apr 20 02:18:29 AM CEST 2023> (x) qtl -band -so -p -dn
Thu Apr 20 02:18:29 AM CEST 2023> (x) lapw2 -p -fermi -so -dn

As you can see the first lapw1 run correctly, it took over one

hour to

calculate 2500 k-points. But then all other programs started
simultaneously, obviously this is wrong. I apologize in advance

for my

inexperience with shell scripts.

I am sure there must be a simple fix!

Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:




http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html


--


--

Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.bl...@tuwien.ac.atWIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at


-

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:


http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html


Links:
--
[1] http://www.numis.northwestern.edu
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] almblm and radwf files

[pluto via Wien]

Dear All,

Below I paste first lines of almblm and radwf files (these particular 
files for WSe2 as an example). Both files consists 5 double columns.


For almblm file each double column is the real and complex part of the 
wave function coefficient.
For radwf file odd columns are radial wave functions, and even columns 
are relativistic corrections.


Sections 2.2.1 and 2.2.2 of the UG describe Alm, Blm, and Clm parameters 
in equations (2.4), (2.7), (2.8) and (2.9). I would like to know which 
parameters in detail are provided how they refer to the columns in 
almblm and radwf files. Are only equations (2.4) and (2.7) used? How do 
I know this? I would appreciate an explanation.


I would also like to know the meaning of metadata in the radwf file. 
What does this line mean in radwf file:


 1 781   0.50   0.0137812254   2.33
   0

I understand 1 is the atom number, 2.33 is the radius of the LAPW sphere 
for atom 1, and it is divided by 781 mesh. But what are the other 
numbers? What is the meaning of the "0" in the second line?


Looking forwards to your comments!

Best,
Lukasz



almblm file:

K-POINT:  0.50  0.50  0.00   432 178  M
   1   1 120  jatom,nemin,nemax
   1   ATOM
   1  1.639344262295082E-002  NUM, weight
   0   0   1 -4.95749920E-12  1.80236721E-022.15699005E-12 
-1.44204821E-020.E+00  0.E+009.52579018E-12 
-2.00412112E-020.E+00  0.E+00
   1  -1   2  1.87594904E-03 -1.08307967E-03   -6.42392401E-03  
3.70885429E-030.E+00  0.E+000.E+00  
0.E+000.E+00  0.E+00
   1   0   3 -6.02351874E-12  1.38565670E-03   -9.93147359E-12 
-4.73459494E-030.E+00  0.E+000.E+00  
0.E+000.E+00  0.E+00
   1   1   4  1.87469540E-03  1.08235587E-03   -6.42537250E-03 
-3.70969058E-030.E+00  0.E+000.E+00  
0.E+000.E+00  0.E+00
   2  -2   5 -1.29349755E-03 -7.46801155E-044.72563496E-03  
2.72834666E-030.E+00  0.E+006.38220100E-04  
3.68476545E-040.E+00  0.E+00
   2  -1   6 -2.33982660E-03  1.35089948E-038.52681233E-03 
-4.92295765E-030.E+00  0.E+001.15041766E-03 
-6.64193948E-040.E+00  0.E+00
   2   0   7  5.52091075E-12 -3.90478967E-043.49583174E-11  
1.40720276E-030.E+00  0.E+001.33271404E-13  
1.90973411E-040.E+00  0.E+00
   2   1   8 -2.34035232E-03 -1.35120300E-038.52545786E-03  
4.92217568E-030.E+00  0.E+001.14467518E-03  
6.60878527E-040.E+00  0.E+00
   2   2   9  1.29405490E-03 -7.47122935E-04   -4.72440748E-03  
2.72763801E-030.E+00  0.E+00   -6.31860091E-04  
3.64804594E-040.E+00  0.E+00
   3  -3  10 -1.29931740E-11 -4.35853957E-04   -4.13707086E-11  
1.68204416E-030.E+00  0.E+000.E+00  
0.E+000.E+00  0.E+00
   3  -2  11  1.56237164E-03  9.02035695E-04   -7.21102337E-03 
-4.16328621E-030.E+00  0.E+000.E+00  
0.E+000.E+00  0.E+00

...


radwf file

 1 781   0.50   0.0137812254   2.33
   0
1.3867667607E-03   -2.3949462449E-022.5535645654E-04   
-4.4100060949E-030.00E+000.00E+00
1.0921041043E-03   -1.8860638269E-020.00E+00
0.00E+00
1.4054046640E-03   -2.4271339045E-022.5878840276E-04   
-4.4692758073E-030.00E+000.00E+00
1.1067817929E-03   -1.9114121956E-020.00E+00
0.00E+00
1.4242930574E-03   -2.4597541607E-022.6226647373E-04   
-4.5293420943E-030.00E+000.00E+00
1.1216567471E-03   -1.9371012420E-020.00E+00
0.00E+00
1.4434217707E-03   -2.4928169238E-022.6578879653E-04   
-4.5902233982E-030.00E+000.00E+00
1.1367209576E-03   -1.9631387553E-020.00E+00
0.00E+00
1.4627757506E-03   -2.5263329860E-022.6935259905E-04   
-4.6519398485E-030.00E+000.00E+00
1.1519625701E-03   -1.9895332138E-020.00E+00
0.00E+00
1.4824017154E-03   -2.5602936860E-022.7296648446E-04   
-4.7144748643E-030.00E+000.00E+00
1.1674183756E-03   -2.0162778472E-020.00E+00
0.00E+00
1.5022852883E-03   -2.5947116838E-022.7662780521E-04   
-4.7778520229E-030.00E+000.00E+00
1.1830770522E-03   -2.0433826043E-020.00E+00
0.00E+00
1.5224358805E-03   -2.6295904860E-022.8033829432E-04   
-4.8420776910E-030.00E+000.00E+00
1.1989460114E-03 

[Wien] shell script issue

[pluto via Wien]

Dear All,

I would like to calculate the sequence of programs to get the band 
characters under bash:


calculate_bands.sh

#! /bin/bash
x lapw1 -band -up -p
x lapw1 -band -dn -p
x lapwso -up -p
x qtl -band -so -p -up
x qtl -band -so -p -dn

I run this from the terminal under Rocky Linux using

calculate_bands.sh &

Here is the result:

Thu Apr 20 01:03:29 AM CEST 2023> (x) lapw1 -band -up -p
Thu Apr 20 02:18:29 AM CEST 2023> (x) lapw1 -band -dn -p
Thu Apr 20 02:18:29 AM CEST 2023> (x) lapwso -up -p
Thu Apr 20 02:18:29 AM CEST 2023> (x) qtl -band -so -p -up
Thu Apr 20 02:18:29 AM CEST 2023> (x) lapw2 -p -fermi -so -up
Thu Apr 20 02:18:29 AM CEST 2023> (x) qtl -band -so -p -dn
Thu Apr 20 02:18:29 AM CEST 2023> (x) lapw2 -p -fermi -so -dn

As you can see the first lapw1 run correctly, it took over one hour to 
calculate 2500 k-points. But then all other programs started 
simultaneously, obviously this is wrong. I apologize in advance for my 
inexperience with shell scripts.


I am sure there must be a simple fix!

Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] w2web fat band plortting does not work with limited energy range in case.inq

[pluto via Wien]

Dear All,

To limit the size of the case.qtl I often limit the energy range and the 
printed atoms in case.inq. For example, out of many atoms I only use 2 
atoms, and I set the -1 to 1 range:


-1.0   1.0   Emin  Emax
   2 number of atoms
   3   1  0  1   iatom,qsplit,symmetrize,locrot
3   0  1  2  nL, l-values
0 0 1
   4   1  0  1   iatom,qsplit,symmetrize,locrot
3   0  1  2  nL, l-values
0 0 1

However, when I do this, and try to plot orbital characters, then 
spaghetti gives an error:


case.outputso created from 4 parallel files
 SPAGH: Read band energy from case.output1
 number of k-points read in case.vector= 153
 error reading QTLs (inconsistent qtl-file):
  band:1211  k-point: 154
  execution continued without fat-bands 
SPAGH END
0.757u 0.101s 0:00.87 97.7% 0+0k 0+46880io 0pf+0w

It seems spaghetti is confused that case.output1 and case.qtl are not 
consistent. But actually, energies are also written in the case.qtl, so 
one does not need any other file to plot energies. And I can plot the 
case.qtl file in Matlab, and everything looks fine (but for quick tests 
w2web is much quicker and convenient).


Is there a setting somewhere to make it work?

Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] Limit the energy range for QTL band character calculation

[pluto via Wien]

I forgot to mention, that I of course run

x lapw1 up/dn -p -band
x lawpso -up

and these calculations are slow if the energy range is not limited. And 
after running these (with that modified case.in1) x qtl makes that error 
I pasted.


The energy range for x qtl can be always limited in case.inq, but this 
is not what I am talking about here.


Best,
Lukasz




On 2023-03-20 23:24, pluto via Wien wrote:

Dear All,

I am trying to limit the energy range of k-point calculations to speed
up the band structure calculations for a large slab. For this reason I
modified the last line in case.in1 into:

K-VECTORS FROM UNIT:4   -1.0   1.0  500   emin / de (emax=Ef+de) / 
nband


Then I tried to run QTL, but got an error:

x qtl -so -band -dn -p

running LAPW2 in parallel mode
LAPW2 - FERMI; weights written
FERMI only
0.072u 0.025s 0:00.09 100.0%0+0k 16+1544io 0pf+0w
running QTL in parallel mode
calculating QTL's from parallel vectors
forrtl: severe (64): input conversion error, unit 8, file case.scf2dn
Image  PCRoutineLine
Source
qtl0043959B  Unknown   Unknown  
Unknown
qtl0045EC80  Unknown   Unknown  
Unknown
qtl0045C940  Unknown   Unknown  
Unknown
qtl00411A00  MAIN__136  
qtlmain.f
qtl00402F62  Unknown   Unknown  
Unknown
libc.so.6  149EA6033EB0  Unknown   Unknown  
Unknown
libc.so.6  149EA6033F60  __libc_start_main Unknown  
Unknown
qtl00402E6E  Unknown   Unknown  
Unknown

0.018u 0.008s 0:00.02 50.0% 0+0k 0+48io 0pf+0w

Regular x lapw2 -band -qtl -up -p works just fine.

Things also work fine with x qtl (but slower) if I don't modify 
case.in1.


Best,
Lukasz


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] Limit the energy range for QTL band character calculation

[pluto via Wien]

Dear All,

I am trying to limit the energy range of k-point calculations to speed 
up the band structure calculations for a large slab. For this reason I 
modified the last line in case.in1 into:


K-VECTORS FROM UNIT:4   -1.0   1.0  500   emin / de (emax=Ef+de) / 
nband


Then I tried to run QTL, but got an error:

x qtl -so -band -dn -p

running LAPW2 in parallel mode
LAPW2 - FERMI; weights written
FERMI only
0.072u 0.025s 0:00.09 100.0%0+0k 16+1544io 0pf+0w
running QTL in parallel mode
calculating QTL's from parallel vectors
forrtl: severe (64): input conversion error, unit 8, file case.scf2dn
Image  PCRoutineLine
Source
qtl0043959B  Unknown   Unknown  
Unknown
qtl0045EC80  Unknown   Unknown  
Unknown
qtl0045C940  Unknown   Unknown  
Unknown
qtl00411A00  MAIN__136  
qtlmain.f
qtl00402F62  Unknown   Unknown  
Unknown
libc.so.6  149EA6033EB0  Unknown   Unknown  
Unknown
libc.so.6  149EA6033F60  __libc_start_main Unknown  
Unknown
qtl00402E6E  Unknown   Unknown  
Unknown

0.018u 0.008s 0:00.02 50.0% 0+0k 0+48io 0pf+0w

Regular x lapw2 -band -qtl -up -p works just fine.

Things also work fine with x qtl (but slower) if I don't modify 
case.in1.


Best,
Lukasz


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] case.almblm along used-defined quantization axis

[pluto via Wien]

 new y new z
LOCAL ROT MATRIX:   -0.500-0.8394340 0.2129568
 0.8660254-0.4846474 0.1229507
 0.000 0.2459014 0.9692949
  Population matrix for TELNES
 Population matrix diagonal in L for L=  0  1  2
 atom  2; type   2; qsplit=  1; for L=  0  1  2
 Symmetrization over eq. k-points is not performed
 allowed for invariant DOS
 New z axis ||1.   1.   1.
 LATTICE:H
  New local rotation matrix in global orthogonal system
   new x new y new z
LOCAL ROT MATRIX:   -0.500-0.8394340 0.2129568
 0.8660254-0.4846474 0.1229507
 0.000 0.2459014 0.9692949
 L=  0. Unitary transformation to Ylm basis
  Real part of unitary matrix
   1.
  Imaginary part of unitary matrix
   0.
 L=  1. Unitary transformation to Ylm basis
  Real part of unitary matrix
   1.   0.   0.
   0.   1.   0.
   0.   0.   1.
  Imaginary part of unitary matrix
   0.   0.   0.
   0.   0.   0.
   0.   0.   0.
 L=  2. Unitary transformation to Ylm basis
  Real part of unitary matrix
   1.   0.   0.   0.   0.
   0.   1.   0.   0.   0.
   0.   0.   1.   0.   0.
   0.   0.   0.   1.   0.
   0.   0.   0.   0.   1.
  Imaginary part of unitary matrix
   0.   0.   0.   0.   0.
   0.   0.   0.   0.   0.
   0.   0.   0.   0.   0.
   0.   0.   0.   0.   0.
   0.   0.   0.   0.   0.
 atom  3; type   3; qsplit=  1; for L=  0  1  2
 Symmetrization over eq. k-points is not performed
 allowed for invariant DOS
 New z axis ||1.   1.   1.
 LATTICE:H
  New local rotation matrix in global orthogonal system
   new x new y new z
LOCAL ROT MATRIX:   -0.500-0.8394340 0.2129568
 0.8660254-0.4846474 0.1229507
 0.000 0.2459014 0.9692949
 L=  0. Unitary transformation to Ylm basis
  Real part of unitary matrix
   1.
  Imaginary part of unitary matrix
   0.
 L=  1. Unitary transformation to Ylm basis
  Real part of unitary matrix
   1.   0.   0.
   0.   1.   0.
   0.   0.   1.
  Imaginary part of unitary matrix
   0.   0.   0.
   0.   0.   0.
   0.   0.   0.
 L=  2. Unitary transformation to Ylm basis
  Real part of unitary matrix
   1.   0.   0.   0.   0.
   0.   1.   0.   0.   0.
   0.   0.   1.   0.   0.
   0.   0.   0.   1.   0.
   0.   0.   0.   0.   1.
  Imaginary part of unitary matrix
   0.   0.   0.   0.   0.
   0.   0.   0.   0.   0.
   0.   0.   0.   0.   0.
   0.   0.   0.   0.   0.
   0.   0.   0.   0.   0.
 LATTICE:H


case.rotlm produced by x qtl

   1.16980   0.0   0.0
   0.58490   1.01308   0.0
   0.0   0.0   0.25701
inequivalent atomnumber   1 number  1 total1
   1.0   0.0   0.0
   0.0   1.0   0.0
   0.0   0.0   1.0
inequivalent atomnumber   1 number  2 total2
  -1.0   0.0   0.0
   0.0  -1.0   0.0
   0.0   0.0   1.0
inequivalent atomnumber   2 number  1 total3
   1.0   0.0   0.0
   0.0   1.0   0.0
   0.0   0.0   1.0
inequivalent atomnumber   2 number  2 total4
  -1.0   0.0   0.0
   0.0  -1.0   0.0
   0.0   0.0   1.0
inequivalent atomnumber   3 number  1 total5
   1.0   0.0   0.0
   0.0   1.0   0.0
   0.0   0.0   1.0
inequivalent atomnumber   3 number  2 total6
  -1.0   0.0   0.0
   0.0  -1.0   0.0
   0.0   0.0   1.0




On 2023-03-19 07:10, Peter Blaha wrote:

For this purpose you can simply redefine the loc.rot. in case.struct
in the way you want it and then call lapw2.

PS: The lapw2-call in   x qtl   is only to get a proper EF and weight 
files.


Am 18.03.2023 um 22:15 schrieb pluto via Wien:

Dear All,

I am again coming back to the Ylm band characters etc...

This command

x lapw2 -up -so -alm -qtl -band

produces case.almblm file. I am guessing that here the quantization 
axis (i.e. the direction of pz and dz2, the z-axis) is oriented along 
the axis defined by the local-rotation-matrices in case.struct 
(actually can be different for each atom).


However, I am interested to have case.almblm file along the 
quantization axis user-defined in case.inq. I tried running


x qtl -band -up -alm -so

But this did not produce case.almblm file. Actually from the :log file 
I can see that x qtl is calling lapw2:


Sat Mar 18 09:37:27 PM

[Wien] case.almblm along used-defined quantization axis

[pluto via Wien]

Dear All,

I am again coming back to the Ylm band characters etc...

This command

x lapw2 -up -so -alm -qtl -band

produces case.almblm file. I am guessing that here the quantization axis 
(i.e. the direction of pz and dz2, the z-axis) is oriented along the 
axis defined by the local-rotation-matrices in case.struct (actually can 
be different for each atom).


However, I am interested to have case.almblm file along the quantization 
axis user-defined in case.inq. I tried running


x qtl -band -up -alm -so

But this did not produce case.almblm file. Actually from the :log file I 
can see that x qtl is calling lapw2:


Sat Mar 18 09:37:27 PM CET 2023> (x) qtl -band -up -alm -so
Sat Mar 18 09:37:27 PM CET 2023> (x) lapw2 -fermi -so -up

Is there any way of printing case.almblm file with the user-defined 
quantization axis?


x qtl produces case.rotlm, which I believe contains new 
local-rotation-matrices. Perhaps I can manually plug these matrices 
somewhere (in case.struct ?) as an input for x lapw2?


Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] i7-13700K benchmarks

[pluto via Wien]

Dear All,

This might be useful for anyone who is building a Linux PC system.

I have some more insight into the speed using i7-13700K, which is the 
current 13th gen Intel CPU. I have Z690-P D4 Asus board and either 128 
GB (4x32) or 64 GB (2x32) Kingston FURY RAM DD4-3600 CL18-22-22 (I can 
just physcially add/remove 2 DIMMs).


With 64 GM RAM the system is seemingly couple of percent faster as 
compared to 128 GB. The reason is probably due to the i7 having only 2 
memory channels (as any other consumer CPU), so having 4 DIMMs probably 
needs extra effort from the memory controller.


Disabling HT and/or VMX in BIOS didn't make a difference. Disabling all 
efficient cores in BIOS didn't make a difference.


Current conclusion is that the bottleneck of this system is the memory 
speed (RAM and probably CPU cache). My previous benchmarks were made 
with DDR4 RAM running at 2400, which is the default top speed for the 
DDR4 RAM. In order to get the RAM running at 3600 one needs to go into 
BIOS and enable the XMP there. My board has two default XMP settings in 
BIOS called XMP-I and XMP-II (one can also manipulate things manually 
but I didn't try). XMP is some protocol which allows the DIMM to tell 
the BIOS at which speed it should run (I think something like this is 
default in DDR5, but for DDR4 is has been added at some point, so older 
DDR4 boards might have a problem with this).


Our IT experts also compiled mpi. Their tests found mpi 10% slower than 
OMP. Maybe problems with compilation... I tried with 20 layer Fe slab 
and also found mpi clearly slower than OMP. So for now I decided not to 
invest time in mpi, I think very big cases are anyway not suitable for 
this system, because of that memory speed bottleneck.


Perhaps same CPU will run faster in parallel execution with DDR5. Also, 
perhaps CPUs with more cache will run faster. But these things are 
expensive, and e.g. the premium AMD CPUs are much more expensive than 
the i7 that I have. Also cache structure seems to be quite complex 
nowadays, so I am not sure if AMD CPUs would be better. Quite obviously, 
at this point efficient cores are useless due to the memory bottleneck.


Some OMP and k-parallel results of my current setup below. I think in 
general 4x localhost and OMP=2 is the winner.


Best,
Lukasz


With XMP-I the system is up over nearly 2 weeks now (so I call it 
stable). The serial benchmark is:


XMP-I, 128 GB DDR4 RAM at 3600, system stable
OMP=1 11.65 seconds
OMP=2 6.93
OMP=3 5.49
OMP=4 4.92
OMP=6 4.09
OMP=8 3.68
OMP=9 4.53
OMP=12 4.41 - 4.85 (results vary within this range more or less)
OMP=16 4.54

In general results can vary maybe by 1% from run to run, I have a 
feeling they are quite stable. I think OMP=12 variation might be related 
to usage or not of efficient cores.


With XMP-II the system is fastest but unstable (PC froze after 2 hours 
and needed hard reboot). The serial benchmark is:


XMP-II, 64 GB DDR4 RAM at 3600, system unstable
OMP=1 12.08
OMP=2 6.87
OMP=3 5.21
OMP=4 4.48
OMP=6 3.92
OMP=8 3.51
OMP=9 4.53
OMP=12 5.07

Previous results (email Feb 22, 2023) with 64GB DDR4 RAM at 2400:
OMP=1 12.82
OMP=2 7.65
OMP=4 5.51
OMP=6 4.87
OMP=8 4.52
OMP=12 5.54
OMP=16 5.55


k-parallel results with 16 k-points (16x Gamma point)
XMP-I, 128 GB DDR4 RAM at 3600, system stable
1x localhost OMP=1 3.05.30 min.sec.
2x localhost OMP=1 1.48.28
2x localhost OMP=2 1.18.23
4x localhost OMP=2 1.03.30
8x localhost OMP=1 1.04.53
8x localhost OMP=2 1.07.19

The best I ever got for this k-parallel test was 0.58.60 with XMP-II 
(system unstable) and 4x localhost OMP=2.




___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] Difference between "x lapw2 -qtl" and "x qtl"

[pluto via Wien]

Dear Prof. Blaha, dear All,

The limit of 25 atoms in QTL is a separate problem, of course. There is 
separate error when exceeding 25 atoms.


Yet another issue is the number of fat bands plotted. Default is 999, 
and in this case it must be increased.


I think that QTL does something more than lapw2 -qtl. I think it is 
related to the "symmetrization" explained in the QTL technical report. 
However, it is not clear if this always allows a correct calculation of 
spin polarization even if equivalent atoms are used. Also, if this is 
the case, then it would mean QTL somehow choses one of the equivalent 
atoms, and plots its character. I suspect if both equivalent atoms 
connected by inversion are chosen, then spin is zero because of the 
Krames degeneracy in a non-magnetic system.


I will test on bulk 2H TMDC, maybe this will clarify things.

Best,
Lukasz

PS: Both atoms are Z>50, so not light. I accepted the options during 
init_so_lapw. Bands looks very much correct, so it is unlikely that 
something is wrong. The material is non magnetic, only spin-momentum 
locked bands can be present.




On 2023-03-15 08:51, Peter Blaha wrote:
Well, we can only guess something because there is not enough 
information.


Clearly:   qtl   has a limit of 25 atoms  in   case.inqtl

It should give you a corresponding error message, so you should be
aware of that.
On the other hand you said you limit the number of atoms to 2 in
case.inqtl, so this should not cause an error.

I would need the struct file together with an exact description of
what you have done and what does not work. Otherwise I cannot
reproduce things.

PS: Why are you setting RLOs for all atoms ?? It does not make sense
for valence electrons of light atoms.

PPS: I'm also surprised that SO with (100) does not break more symmetry 
???



Am 15.03.2023 um 01:32 schrieb pluto via Wien:

Dear All,

I am calculating one of the 1T TMDC materials. This material e.g. has 
a spin-polarized Dirac cone on the surface (see e.g. DOI 
10.1088/2516-1075/ab09b7 for review of similar materials).


I calculated 10L (15 inequivalent atoms) and 20L (30 inequivalent 
atoms) slabs. I allowed sgroup to find the space group (no. 164) in 
order to speed up the calculation. In this case it means each 
inequivalent atom has 2 equivalent positions.


It is a spin polarized calculation with SOC. Band structures look good 
compared to the literature Wannier calculations.


One obvious test is to check spin polarization of the Dirac cone.

Band characters can be calculated either using
x lapw2 -band -qtl -up/dn -so (default in w2web)
or using
x qtl -band -up/dn -so

Importantly, in order to make x qtl work I need to
cp case.in1 case.in1c
although the system does have inversion (otherwise qtl gives an error 
and nothing is calculated). Is this allowed?


Another problem is that for the 20L slab x spaghetti does not want to 
plot fat bands out of case.qtlup/dn produced by "x qtl". I didn't look 
at the case.qtlup/dn files in detail yet (I will, but it might take a 
while), but either they are incomplete (i.e. x qtl cannot handle a big 
slab), or spaghetti cannot handle these files beyond a certain size 
limit. On the other hand case.qtlup/dn produced by x lapw2 always work 
with fat bands. Of couse when using x qtl I limit the number of atoms 
in case.inq, and I typically only calculate characters for 2 outermost 
atoms (my case.inq pasted below). For 10L slab everything works fine.


The plotted results (using w2web) for these two cases look very 
different. I tried plotting characters on couple of outermost atoms.


x lapw2 does not show any spin polarization of the Dirac cone
x qtl shows clear very high polarization of the Dirac cone

This happens when I plot total character on a particular atom, is it 
not an effect related to some Y_lm character or things like that.


I think in general I should split all atoms in order to get correct 
spin polarization (the so-called hidden spin polarization introduced 
by Zunger/Freeman). This is what one had to do with the 2H MoS2 
calculations several years back. But splitting all atoms would 
probably make 20L slab calculation prohibitive on my system (I think 
20L would be unrealistic).


But perhaps the QTL program can somehow do the job of splitting the 
equivalent atoms even on slab with equivalent positions.


I also paste below case.inso, note that the direction of spin 
polarization quant. axis is along 100, i.e. in-plane, as it should for 
these materials.


Best,
Lukasz


case.inq file:

-9.0   3.0   Emin  Emax
   2 number of atoms
    1   1  0  1   iatom,qsplit,symmetrize,locrot
3   0  1  2  nL, l-values
0 0 1
   30   1  0  1   iatom,qsplit,symmetrize,locrot
3   0  1  2  nL, l-values
0 0 1

case.inso

WFFIL
4  0  0 llmax,ipr,kpot
-10  1.9    Emin, Emax
     1 0 0   h,k,l (direction o

[Wien] Difference between "x lapw2 -qtl" and "x qtl"

[pluto via Wien]

Dear All,

I am calculating one of the 1T TMDC materials. This material e.g. has a 
spin-polarized Dirac cone on the surface (see e.g. DOI 
10.1088/2516-1075/ab09b7 for review of similar materials).


I calculated 10L (15 inequivalent atoms) and 20L (30 inequivalent atoms) 
slabs. I allowed sgroup to find the space group (no. 164) in order to 
speed up the calculation. In this case it means each inequivalent atom 
has 2 equivalent positions.


It is a spin polarized calculation with SOC. Band structures look good 
compared to the literature Wannier calculations.


One obvious test is to check spin polarization of the Dirac cone.

Band characters can be calculated either using
x lapw2 -band -qtl -up/dn -so (default in w2web)
or using
x qtl -band -up/dn -so

Importantly, in order to make x qtl work I need to
cp case.in1 case.in1c
although the system does have inversion (otherwise qtl gives an error 
and nothing is calculated). Is this allowed?


Another problem is that for the 20L slab x spaghetti does not want to 
plot fat bands out of case.qtlup/dn produced by "x qtl". I didn't look 
at the case.qtlup/dn files in detail yet (I will, but it might take a 
while), but either they are incomplete (i.e. x qtl cannot handle a big 
slab), or spaghetti cannot handle these files beyond a certain size 
limit. On the other hand case.qtlup/dn produced by x lapw2 always work 
with fat bands. Of couse when using x qtl I limit the number of atoms in 
case.inq, and I typically only calculate characters for 2 outermost 
atoms (my case.inq pasted below). For 10L slab everything works fine.


The plotted results (using w2web) for these two cases look very 
different. I tried plotting characters on couple of outermost atoms.


x lapw2 does not show any spin polarization of the Dirac cone
x qtl shows clear very high polarization of the Dirac cone

This happens when I plot total character on a particular atom, is it not 
an effect related to some Y_lm character or things like that.


I think in general I should split all atoms in order to get correct spin 
polarization (the so-called hidden spin polarization introduced by 
Zunger/Freeman). This is what one had to do with the 2H MoS2 
calculations several years back. But splitting all atoms would probably 
make 20L slab calculation prohibitive on my system (I think 20L would be 
unrealistic).


But perhaps the QTL program can somehow do the job of splitting the 
equivalent atoms even on slab with equivalent positions.


I also paste below case.inso, note that the direction of spin 
polarization quant. axis is along 100, i.e. in-plane, as it should for 
these materials.


Best,
Lukasz


case.inq file:

-9.0   3.0   Emin  Emax
  2 number of atoms
   1   1  0  1   iatom,qsplit,symmetrize,locrot
3   0  1  2  nL, l-values
0 0 1
  30   1  0  1   iatom,qsplit,symmetrize,locrot
3   0  1  2  nL, l-values
0 0 1

case.inso

WFFIL
4  0  0 llmax,ipr,kpot
-10  1.9Emin, Emax
1 0 0   h,k,l (direction of magnetization)
 30   number of atoms with RLO
1 -3.53 0.0001 STOP atom-number, E-param for RLO
2 -3.53 0.0001 STOP atom-number, E-param for RLO
3 -3.53 0.0001 STOP atom-number, E-param for RLO
4 -3.53 0.0001 STOP atom-number, E-param for RLO
5 -3.53 0.0001 STOP atom-number, E-param for RLO
6 -3.53 0.0001 STOP atom-number, E-param for RLO
7 -3.53 0.0001 STOP atom-number, E-param for RLO
8 -3.53 0.0001 STOP atom-number, E-param for RLO
9 -3.53 0.0001 STOP atom-number, E-param for RLO
10 -3.53 0.0001 STOP atom-number, E-param for RLO
11 0.30 0. CONT atom-number, E-param for RLO
12 0.30 0. CONT atom-number, E-param for RLO
13 0.30 0. CONT atom-number, E-param for RLO
14 0.30 0. CONT atom-number, E-param for RLO
15 0.30 0. CONT atom-number, E-param for RLO
16 0.30 0. CONT atom-number, E-param for RLO
17 0.30 0. CONT atom-number, E-param for RLO
18 0.30 0. CONT atom-number, E-param for RLO
19 0.30 0. CONT atom-number, E-param for RLO
20 0.30 0. CONT atom-number, E-param for RLO
21 0.30 0. CONT atom-number, E-param for RLO
22 0.30 0. CONT atom-number, E-param for RLO
23 0.30 0. CONT atom-number, E-param for RLO
24 0.30 0. CONT atom-number, E-param for RLO
25 0.30 0. CONT atom-number, E-param for RLO
26 0.30 0. CONT atom-number, E-param for RLO
27 0.30 0. CONT atom-number, E-param for RLO
28 0.30 0. CONT atom-number, E-param for RLO
29 0.30 0. CONT atom-number, E-param for RLO
30 0.30 0. CONT atom-number, E-param for RLO
0 0  number of atoms 

Re: [Wien] Parallel execution on new Intel CPUs

[pluto via Wien]

Dear Prof. Blaha, Prof. Marks, dear All,

Below some benchmark results. It seems that for a serial calculation 
using 8 OMP threads is optimal. This probably has something to do with 
having 8 fast and 8 slow cores.


Hardware:
13th Gen Intel(R) Core(TM) i7-13700K
64 GB of RAM DDR4-3600
2 TB drive Samsung NVMe
ASUS Z690-P D4 mainboard

I also looked at mpi-benchmark, but I don't have mpi, so I think these 
tests make no sense.


Let me know if I shoud add something to this.

Best,
Lukasz



bash-5.1$ pwd
(...)/WIEN2k_benchmark/Serial/test_case

bash-5.1$ export OMP_NUM_THREADS=1
bash-5.1$ echo $OMP_NUM_THREADS
1
bash-5.1$ x lapw1
 LAPW1 END
12.567u 0.216s 0:12.82 99.6%0+0k 464+37840io 2pf+0w

bash-5.1$ export OMP_NUM_THREADS=2
bash-5.1$ echo $OMP_NUM_THREADS
2
bash-5.1$ x lapw1
 LAPW1 END
14.844u 0.248s 0:07.65 197.1%   0+0k 0+37840io 2pf+0w


bash-5.1$ export OMP_NUM_THREADS=4
bash-5.1$ echo $OMP_NUM_THREADS
4
bash-5.1$ x lapw1
 LAPW1 END
21.091u 0.372s 0:05.51 389.4%   0+0k 0+37840io 10pf+0w

bash-5.1$ export OMP_NUM_THREADS=6
bash-5.1$ echo $OMP_NUM_THREADS
6
bash-5.1$ x lapw1
 LAPW1 END
27.765u 0.490s 0:04.87 580.0%   0+0k 0+37824io 19pf+0w

bash-5.1$ export OMP_NUM_THREADS=8
bash-5.1$ echo $OMP_NUM_THREADS
8
bash-5.1$ x lapw1
 LAPW1 END
34.099u 0.605s 0:04.51 769.1%   0+0k 0+37824io 27pf+0w
bash-5.1$ x lapw1
 LAPW1 END
34.087u 0.616s 0:04.51 769.1%   0+0k 0+37824io 33pf+0w
bash-5.1$ x lapw1
 LAPW1 END
34.119u 0.629s 0:04.52 768.3%   0+0k 0+37824io 26pf+0w
bash-5.1$ x lapw1
 LAPW1 END
34.234u 0.579s 0:04.53 768.2%   0+0k 0+37824io 26pf+0w

bash-5.1$ export OMP_NUM_THREADS=12
bash-5.1$ echo $OMP_NUM_THREADS
12
bash-5.1$ x lapw1
 LAPW1 END
61.638u 2.193s 0:05.54 1151.9%  0+0k 0+37840io 44pf+0w

bash-5.1$ export OMP_NUM_THREADS=16
bash-5.1$ echo $OMP_NUM_THREADS
16
bash-5.1$ x lapw1
 LAPW1 END
82.629u 2.636s 0:05.55 1536.0%  0+0k 0+37840io 63pf+0w

bash-5.1$ export OMP_NUM_THREADS=24
bash-5.1$ echo $OMP_NUM_THREADS
24
bash-5.1$ x lapw1
 LAPW1 END
86.794u 3.724s 0:05.48 1651.6%  0+0k 0+37840io 57pf+0w




bash-5.1$ pwd
(...)/WIEN2k_benchmark/mpi-benchmark
bash-5.1$ export OMP_NUM_THREADS=1
bash-5.1$ echo $OMP_NUM_THREADS
1
bash-5.1$ x lapw1
 LAPW1 END
117.827u 0.921s 1:58.88 99.8%   0+0k 432+162616io 2pf+0w




On 2023-02-15 01:11, Laurence Marks wrote:

Two things:

1) The CPU you have looks interesting. Can you please run and post the
benchmark from the Wien2k page for different omp (and mpi would be
good). It would be good to know what the "Hybrid Core" architecture
does with Wien2k. For mpi elpa is much better -- it can also be better
for non-mpi.

2) It is established lore in the DFT community that increasing the
"smearing" assists convergence. However, not all lore is true. I am
aware of zero evidence for this with the current Wien2k mixer, so I
suggest sticking with room temperature rather than 1500K. More
important is a well-posed problem. For more see
http://www.numis.northwestern.edu/Presentations/DFT_Mixing_For_Dummies.pdf

On Tue, Feb 14, 2023 at 5:18 PM pluto via Wien
 wrote:


Dear Prof. Blaha,

Thank you for comments.

At the moment I have 56 k-points in a big slab of one of the ternary

magnetic 2D materials. Perhaps I can reduce k-points, something to
test.
Also now I see that my 56 k-points are compatible with 1:localhost
lines
:-)

Also, for now it does not want to converge after 40 iterations with
TEMP
0.002, for a while I was trying TEMP 0.004, and now I am trying TEMP

0.01. Maybe I should start with a smaller slab...

Some info you asked for:

The i7-13700K CPU has 8 P-cores (fast) and 8 E-cores (slow), so 16
total
physical cores. Each P-core has 2 threads, so there are total of 24
threads. Many other new Intel CPUs are the same. I don't think there
is
an easy way to enforce certain task on a certain core, and probably
it
makes no sense, because the CPU for sure has thermal control over
different cores etc.


 --

Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
https://scholar.google.com/citations?user=zmHhI9gJ=en [1]
"Research is to see what everybody else has seen, and to think what
nobody else has thought", Albert Szent-Györgyi

Links:
--
[1] http://www.numis.northwestern.edu
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] Energy of 4f levels in paramagnetic bands

[pluto via Wien]

Is there a way to artificially shift the 4s level somewhere?


Of course I meant the 4f level. Sorry for the typo.

Lukasz


On 2023-02-20 12:19, pluto via Wien wrote:

Dear All,

I am calculating one of the Kagome materials. It includes a 4f element.

I need non-magnetic bands, because my experiments are made above the
magnetic transition temperature. People typically use U around 6 eV on
the 4f level for this material. I know that paramagnetic phase of
local-moment 4f compound is more complicated, but people often
approximate it with non-magnetic DFT bands.

The problem is that without FM the 4f bands are not exchange split and
they land around the Fermi level, obscuring the interesting valence
bands. And with magnetic calculation (runsp) all non-4f bands are
slightly exchange split, which I need to avoid.

Is there a way to artificially shift the 4s level somewhere? Or just
to remove them, treat them as core? I understand these kind of
procedures are called the "frozen core approx.".

Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] Energy of 4f levels in paramagnetic bands

[pluto via Wien]

Dear All,

I am calculating one of the Kagome materials. It includes a 4f element.

I need non-magnetic bands, because my experiments are made above the 
magnetic transition temperature. People typically use U around 6 eV on 
the 4f level for this material. I know that paramagnetic phase of 
local-moment 4f compound is more complicated, but people often 
approximate it with non-magnetic DFT bands.


The problem is that without FM the 4f bands are not exchange split and 
they land around the Fermi level, obscuring the interesting valence 
bands. And with magnetic calculation (runsp) all non-4f bands are 
slightly exchange split, which I need to avoid.


Is there a way to artificially shift the 4s level somewhere? Or just to 
remove them, treat them as core? I understand these kind of procedures 
are called the "frozen core approx.".


Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] Slab convergence

[pluto via Wien]

nvergence:  0 0. .0593245
:CHARGE convergence:  0 0. .0805541
:CHARGE convergence:  0 0. .0941134
:CHARGE convergence:  0 0. .0577276
:CHARGE convergence:  0 0. .0687931
:CHARGE convergence:  0 0. .0356519
:CHARGE convergence:  0 0. .0312231
:CHARGE convergence:  0 0. .0360658
:CHARGE convergence:  0 0. .0325906
:CHARGE convergence:  0 0. .0335829
:CHARGE convergence:  0 0. .0250306
:CHARGE convergence:  0 0. .0223318
:CHARGE convergence:  0 0. .0200267
:CHARGE convergence:  0 0. .0143537
:CHARGE convergence:  0 0. .0225022
:CHARGE convergence:  0 0. .0160182
:CHARGE convergence:  0 0. .0104271
:CHARGE convergence:  0 0. .0064069
:CHARGE convergence:  0 0. .0060072
:CHARGE convergence:  0 0. .0546401
:CHARGE convergence:  0 0. .0635523
:CHARGE convergence:  0 0. .0574923
:CHARGE convergence:  0 0. .0768055
:CHARGE convergence:  0 0. .0126418


 1 0 0 011  1.0 -7.0  1.5
40 k, div: ( 11 11  1)

 2 0 1 011  2.0
 3 0 2 011  2.0
 4 0 3 011  2.0
 5 0 4 011  2.0
 6 0 5 011  2.0
 7 1 0 011  4.0
 8 1 1 011  4.0
 9 1 2 011  4.0
10 1 3 011  4.0
11 1 4 011  4.0
12 1 5 011  2.0
13 2 0 011  4.0
14 2 1 011  4.0
15 2 2 011  4.0
16 2 3 011  4.0
17 2 4 011  4.0
18 210 011  2.0
19 3 0 011  4.0
20 3 1 011  4.0
21 3 2 011  4.0
22 3 3 011  4.0
23 3 4 011  2.0
24 3 9 011  4.0
25 4 0 011  4.0
26 4 1 011  4.0
27 4 2 011  4.0
28 4 3 011  4.0
29 4 8 011  4.0
30 4 9 011  2.0
31 5 0 011  4.0
32 5 1 011  4.0
33 5 2 011  4.0
34 5 3 011  2.0
35 5 7 011  4.0
36 5 8 011  4.0



On 2023-02-15 01:11, Laurence Marks wrote:

Two things:

1) The CPU you have looks interesting. Can you please run and post the
benchmark from the Wien2k page for different omp (and mpi would be
good). It would be good to know what the "Hybrid Core" architecture
does with Wien2k. For mpi elpa is much better -- it can also be better
for non-mpi.

2) It is established lore in the DFT community that increasing the
"smearing" assists convergence. However, not all lore is true. I am
aware of zero evidence for this with the current Wien2k mixer, so I
suggest sticking with room temperature rather than 1500K. More
important is a well-posed problem. For more see
http://www.numis.northwestern.edu/Presentations/DFT_Mixing_For_Dummies.pdf

On Tue, Feb 14, 2023 at 5:18 PM pluto via Wien
 wrote:


Dear Prof. Blaha,

Thank you for comments.

At the moment I have 56 k-points in a big slab of one of the ternary

magnetic 2D materials. Perhaps I can reduce k-points, something to
test.
Also now I see that my 56 k-points are compatible with 1:localhost
lines
:-)

Also, for now it does not want to converge after 40 iterations with
TEMP
0.002, for a while I was trying TEMP 0.004, and now I am trying TEMP

0.01. Maybe I should start with a smaller slab...

Some info you asked for:

The i7-13700K CPU has 8 P-cores (fast) and 8 E-cores (slow), so 16
total
physical cores. Each P-core has 2 threads, so there are total of 24
threads. Many other new Intel CPUs are the same. I don't think there
is
an easy way to enforce certain task on a certain core, and probably
it
makes no sense, because the CPU for sure has thermal control over
different cores etc.


 --

Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
https://scholar.google.com/citations?user=zmHhI9gJ=en [1]
"Research is to see what everybody else has seen, and to think what
nobody else has thought", Albert Szent-Györgyi

L

Re: [Wien] QTL quantization axis for Y_lm orbitals

[pluto via Wien]

Dear Prof. Blaha,

I looked the case.radwf file. For my test case of bulk-fcc-Al it 
consists to following header:


   1 781   0.000100   0.0129828604   2.50

Here "1" seems to indicate the atom number from the case.struct (there 
is only one inequivalent for fcc Al) and "781" indicates the number of 
mesh points between the center of the atom and the radius of the sphere 
(starting at the radius and ending at the center). Radius in this case 
is 2.5 Bohr, as also indicated.


After this there are sections, each with 781 rows. These sections are 
marked by 0, 1, 2, 3...8 which for me seems to be s, p, d, f, ...


Now each of these sections contains up to 10 columns. Can you explain 
the meaning of these columns?


To me it looks as if 2 columns are assigned to each of u, u-dot, u_lo, 
... But I would expect a single column of real numbers, in the spirit of 
R_nl for the hydrogen.


I plotted some of these columns for check, and the first columns of the 
first section looks like 3s, but the second column looks a bit strange.


Best,
Lukasz









On 2023-02-13 10:21, Peter Blaha wrote:

It was mentioned several times on the mailing list that

x lapw2 -alm

prints the radial functions into a file (just once) as well as all
Alm,Blm,... for each k-point and band-index.

For further details search the mailing list.

For the interstitial matrix elements you can get them by the integral
between two plane wave expansions (times the dipole operator ?)
multiplied with the "step-function". Such detaisl are well explained
in D. Singh's book...


Am 12.02.2023 um 20:10 schrieb pluto via Wien:

Dear Prof. Blaha,

Thank you for your comments.

Are the functions u and u-dot provided in some output file? Manual 
mentions different types of u and u-dot for the cases of Psi^LO and 
Psi^lo. Manual also mentions that u and u-dot are obtained by 
numerical integration of radial Schrodinger equation on the mesh. Are 
they all tabulated somewhere?


Having all the A_lm, B_lm, C_lm and all the u and u-dot would allow to 
have the full wave function Psi(r) inside the spheres as a function of 
wave-vector and energy. That would allow to numerically calculate the 
matrix elements which I need, with the assumption of my favorite final 
state, and without any further assumptions. The only remaining problem 
would be the interstitial region, but it would also be under control 
by knowing how much charge leaks out of the spheres.


Best,
Lukasz




On 2023-02-09 18:06, Peter Blaha wrote:
Well, I'm not sure I do understand all your problems, but a few 
comments:


a) XMCD is implemented in   optics !

b) I do not see the problem with A_lm, B_lm C_lm,..., because in any
case  A_lm (or for semicore a C_lm) will dominate and you can 
probably

neglect the B_lm and the corresponding u-dot radial function.

When you chose a good expansion energy for your radial wf., you more
or less have this "hydrogenic orbital" with one fixed radial 
function.

Of course, this argument holds only when your states are "localized",
otherwise you will have a large interstital (PW) contribution.

c) I'm not the real expert of Wannier functions, but I guess the WF
might be complicated linear combinations of different l,m ....



Am 09.02.2023 um 15:46 schrieb pluto via Wien:

Dear Sylwia, dear Prof. Blaha, dear All,

Having these A_lm, B_lm etc is of course a problem if one wants to 
estimate interferences in dipole optical matrix element due to 
phases at which different Y_lm orbitals enter the wave function. It 
would be good to have a single complex number per Y_lm.


For this it would be good to have the LAPW wavefunction projected 
onto hydrogenic orbitals that just have a single radial component. 
Then there would be just one complex coefficient. For a particular l 
(i.e. s, p, or d) one would have a common radial part of the wave 
function, since the radial part does not depend on m. Then one would 
need to assume the final state expansion in Y_lm (can always be done 
even for free-electron final state) and do some estimation of the 
XMCD process within the simplified LCAO way of thinking.


Is there any tool already existing to project WIEN2k wave function 
onto hydrogenic orbitals?
I was thinking something like this might be a part of the 
WIEN2Wannier, but I wanted to ask here before investing further time 
into this.


Best,
Lukasz



___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at: 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] Definition of directions in QTL band character calculations

[pluto via Wien]

Dear All,

I am interested in calculating different types of orbital characters.

When calculating a TMDC of 1T type (space group 164) I experience the 
following:


(A). When using regular commands (x lapw2 -band -qtl -up/dn -so) I am 
having x swapped with z. Perhaps also other things happen, according to 
Loc-Rot matrices in case.struct. This is explained in UG, page 277.


(B). When using QTL to calculate characters, with loro=0 I have the same 
result as in point (A).


(C). When using QTL to calculate characters with loro=1, and setting the 
"new-z-axis" to "0 0 1", I am having the pz orbital facing out of plane 
of the layers (i.e. along the hexagonal c-axis). This is of course a 
good starting point for anyone who compares bands to ARPES data.


I just want to make sure, if I understand the logic of this. I 
understand that with "lapw2 -qtl" and with "qtl, loro=0" the coordinate 
system is rotated according to the Loc-Rot matrices from the 
case.struct. I also understand that these Loc-Rot matrices can be in 
principle different for each inequivalent atom, so in principle setting 
"pz" for atom 1 can be physically a different direction than "pz" for 
atom 2.


Now I am not sure to which axis the program QTL refers when loro=1 (or 
loro=2). It seems to me that it somehow refers to the hexagonal 
coordinate system defined in the case.struct. For a layered hexagonal 
system, conventionally this would mean a-b-c, with c being out-of-plane 
of the layers, and with 120 deg between a and b. Lets say that a-b-c 
transforms into h-k-l in the reciprocal space. Then l (and c) are 
out-of-plane, so in Cartesian system it is parallel to z=(001). But what 
are x and y of the Cartesian system? For "qtl, loro=2", "new z-axis 0 0 
1", "new x axis 1 0 0" is x=(100) direction parallel to a? Or maybe 
parallel to h? (y would be determined this way).


In other words, with "qtl loro=2', "new z-axis 0 0 1", "new x axis 1 0 
0", would the new x-axis be along Gamma-M or along Gamma-K?


How would this work for the rhombohedral system (layered 2D system)? 
Because for the k-list of the rhombohedral system one needs to use the 
rhombohedral reciprocal vectors, while in the case.struct file one 
provides hexagonal lattice parameters (this was discussed many times in 
the forum), and for real orbitals we need Cartesian system... Would QTL 
with loro=1 again set the z-axis out of plane of the layers according to 
the hexagonal abc (or hkl)?


Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] Parallel execution on new Intel CPUs

[pluto via Wien]

Dear Prof. Blaha,

Thank you for comments.

At the moment I have 56 k-points in a big slab of one of the ternary 
magnetic 2D materials. Perhaps I can reduce k-points, something to test. 
Also now I see that my 56 k-points are compatible with 1:localhost lines 
:-)


Also, for now it does not want to converge after 40 iterations with TEMP 
0.002, for a while I was trying TEMP 0.004, and now I am trying TEMP 
0.01. Maybe I should start with a smaller slab...


Some info you asked for:

The i7-13700K CPU has 8 P-cores (fast) and 8 E-cores (slow), so 16 total 
physical cores. Each P-core has 2 threads, so there are total of 24 
threads. Many other new Intel CPUs are the same. I don't think there is 
an easy way to enforce certain task on a certain core, and probably it 
makes no sense, because the CPU for sure has thermal control over 
different cores etc.


It seems this new Intel CPU is quite good in balancing the load on 
different CPUs. In this slab, one lapw1 cycle takes approx. an hour, 
here a most recent example with 8x 1:localhost and OMP=3 (i.e. slight 
overload, it is a bit faster than 16x 1:localhost):


Here a part of the case.dayfile:
  lapw1  -dn -p   (22:15:21) starting parallel lapw1 at Tue Feb 14 
10:15:21 PM CET 2023

->  starting parallel LAPW1 jobs at Tue Feb 14 10:15:21 PM CET 2023
running LAPW1 in parallel mode (using .machines.help)
8 number_of_parallel_jobs
 localhost(7) 7846.370u 123.112s 57:21.99 231.54%  0+0k 0+0io 
0pf+0w
 localhost(7) 8073.008u 126.002s 56:16.88 242.80%  0+0k 0+0io 
0pf+0w
 localhost(7) 7859.701u 110.324s 54:47.53 242.43%  0+0k 0+0io 
0pf+0w
 localhost(7) 8073.152u 95.375s 56:33.84 240.69%  0+0k 0+0io 
0pf+0w
 localhost(7) 7531.787u 90.177s 57:48.78 219.73%  0+0k 0+0io 
0pf+0w
 localhost(7) 7883.831u 100.913s 55:39.61 239.09%  0+0k 0+0io 
0pf+0w
 localhost(7) 7980.689u 114.522s 56:04.84 240.58%  0+0k 0+0io 
0pf+0w
 localhost(7) 8113.984u 98.149s 56:10.74 243.63%  0+0k 0+0io 
0pf+0w

   Summary of lapw1para:
   localhost k=56user=63362.5wallclock=27044.2
17.563u 48.090s 57:50.56 1.8%   0+0k 0+1520io 5pf+0w


Here a part of :log
Tue Feb 14 09:17:38 PM CET 2023> (x) mixer
Tue Feb 14 09:17:41 PM CET 2023> (x) lapw0 -p
Tue Feb 14 09:18:05 PM CET 2023> (x) lapw1 -up -p
Tue Feb 14 10:15:21 PM CET 2023> (x) lapw1 -dn -p
Tue Feb 14 11:13:11 PM CET 2023> (x) lapw2 -up -p
Tue Feb 14 11:18:32 PM CET 2023> (x) sumpara -up -d
Tue Feb 14 11:18:32 PM CET 2023> (x) lapw2 -dn -p
Tue Feb 14 11:23:42 PM CET 2023> (x) sumpara -dn -d
Tue Feb 14 11:23:42 PM CET 2023> (x) lcore -up
Tue Feb 14 11:23:42 PM CET 2023> (x) lcore -dn
Tue Feb 14 11:23:43 PM CET 2023> (x) mixer

.machines file:
omp_global:12
omp_lapw1:3
omp_lapw2:3
1:localhost
1:localhost
1:localhost
1:localhost
1:localhost
1:localhost
1:localhost
1:localhost
granularity:1


I think in my case mpi won't make much difference. With "so many" cores 
on a single CPU and seemingly quite decent automatic load balancing I 
should always be able to find a good way to find balance between proper 
number of 1:localhosts and OMP. I don't think I will ever be calculating 
really big cases with very few k-points, these things should in any case 
be done on a cluster.


Best,
Lukasz



On 2023-02-14 12:00, Peter Blaha wrote:

How many k-points do you have ? (And how many cores in total ?)

The number of lines (8 or 16) needs to be "compatible" with the number
of k-points. I have no experience how the memory-bus of this cpu is
and how "equal" the load is distributed. You need to check the dayfile
and check if eg. all 16 parallel lapw1 jobs finished at about the same
time, or 8 run much longer then the other set.

The mpi-code can be quite efficient and for medium sized cases of
similar speed, but for this it is mandatory to install the ELPA
library.
For large cases you usually have only few k-points and clearly only
with mpi you can use many cores/cpus. For a 36-atom slab I probably
would not run the regular scf cycle with more than 16 k-points in the
IBZ (at least if it is insulating) and thus mpi gives a chance to
speed-up things.

Again, I do not know what 16 mpi-jobs do, if 8 cores are fast and 8 are 
slow ?



Am 14.02.2023 um 11:32 schrieb pluto via Wien:

Dear Profs. Blaha, Marks,

Thank you for the information!

Could you give an estimate what could be a possible speed-up when I 
use mpi parallelization?


My tests on 36-inequivalent-atom slab so far indicate that there is 
nearly no difference between different k-parallel and OMP settings. So 
far I tried


8x 1:localhost with OMP=2
16x 1:localhost with OMP=1
16x 1:localhost with OMP=2 (means slight overloading)

and the time per SCF cycle (runsp without so) is practically the same 
in all these. Later I will also try higher OMP with less 1:localhost, 
but I doubt this can possibly be faster.


I have i7-13700K with 64 GB of RAM an

Re: [Wien] Parallel execution on new Intel CPUs

[pluto via Wien]

Dear Profs. Blaha, Marks,

Thank you for the information!

Could you give an estimate what could be a possible speed-up when I use 
mpi parallelization?


My tests on 36-inequivalent-atom slab so far indicate that there is 
nearly no difference between different k-parallel and OMP settings. So 
far I tried


8x 1:localhost with OMP=2
16x 1:localhost with OMP=1
16x 1:localhost with OMP=2 (means slight overloading)

and the time per SCF cycle (runsp without so) is practically the same in 
all these. Later I will also try higher OMP with less 1:localhost, but I 
doubt this can possibly be faster.


I have i7-13700K with 64 GB of RAM and NVMe SSD. During 36-atom-slab 
parallel calculation around 35 GB is used.


Best,
Lukasz

PS: Now omp_lapwso also works for me in .machines. I think it was a SOC 
issue with my test case (which was bulk Au). I am sorry for this 
confusion.





On 2023-02-14 10:23, Peter Blaha wrote:

I have no experience for such a CPU with fast and slow cores.

Simply test it out how you get the fastest turnaround for a fixed
number of k-points and different number of processes (should be
compatible with your k-points) and OMP=1-2 (4).

Previously, overloading (using more cores than the physical cores) was
NOT a good idea, but I don't know how this "fused" CPU behaves. Maybe
some "small" overloading is ok. This all depends on #-kpoints and
available cores.

PS:

I cannot verify your omp_lapwso:2 failure. My tests run fine and the
omp-setting is taken over properly.




I am now using a machine with i7-13700K. This CPU has 8 performance 
cores (P-cores) and 8 efficient cores (E-cores). In addition each 
P-core has 2 threads, so there is 24 threads alltogether. It is hard 
to find some reasonable info online, but probably a P-core is approx. 
2x faster than an E-core:
https://www.anandtech.com/show/17047/the-intel-12th-gen-core-i912900k-review-hybrid-performance-brings-hybrid-complexity/10 
This will of course depend on what is being calculated...


Do you have suggestions on how to optimize the .machines file for the 
parallel execution of an scf cycle?


On my machine using OMP_NUM_THREADS leads to oscillations of the CPU 
use (for a large slab maybe 40% of time is spent on a single thread), 
suggesting that large OMP is not the optimal strategy.


Some examples of strategies:

One strategy would be to repeat the line
1:localhost
24 times, to have all the threads busy, and set OMP_NUM_THREADS=1.

Another would be set the line
1:localhost
8 times and set OMP_NUM_THREADS=2, this would mean using all 16 
physical cores.


Or perhaps one should better "overload" the CPU e.g. by doing 
1:localhost 16 times and OMP=2 ?


Over time I will try to benchmark some the different options, but 
perhaps there is some logic of how one should think about this.


In addition I have a comment on .machines file. It seems that for the 
FM+SOC (runsp -so) calculations the


omp_global

setting in .machines is ignored. The

omp_lapw1
omp_lapw2

settings seem to work fine. So, I tried to set OMP for lapwso 
separately, by including the line like:


omp_lapwso:2

but this gives an error when executing parallel scf.

Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at: 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] Parallel execution on new Intel CPUs

[pluto via Wien]

Dear All,

I am now using a machine with i7-13700K. This CPU has 8 performance 
cores (P-cores) and 8 efficient cores (E-cores). In addition each P-core 
has 2 threads, so there is 24 threads alltogether. It is hard to find 
some reasonable info online, but probably a P-core is approx. 2x faster 
than an E-core:

https://www.anandtech.com/show/17047/the-intel-12th-gen-core-i912900k-review-hybrid-performance-brings-hybrid-complexity/10
This will of course depend on what is being calculated...

Do you have suggestions on how to optimize the .machines file for the 
parallel execution of an scf cycle?


On my machine using OMP_NUM_THREADS leads to oscillations of the CPU use 
(for a large slab maybe 40% of time is spent on a single thread), 
suggesting that large OMP is not the optimal strategy.


Some examples of strategies:

One strategy would be to repeat the line
1:localhost
24 times, to have all the threads busy, and set OMP_NUM_THREADS=1.

Another would be set the line
1:localhost
8 times and set OMP_NUM_THREADS=2, this would mean using all 16 physical 
cores.


Or perhaps one should better "overload" the CPU e.g. by doing 
1:localhost 16 times and OMP=2 ?


Over time I will try to benchmark some the different options, but 
perhaps there is some logic of how one should think about this.


In addition I have a comment on .machines file. It seems that for the 
FM+SOC (runsp -so) calculations the


omp_global

setting in .machines is ignored. The

omp_lapw1
omp_lapw2

settings seem to work fine. So, I tried to set OMP for lapwso 
separately, by including the line like:


omp_lapwso:2

but this gives an error when executing parallel scf.

Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] QTL quantization axis for Y_lm orbitals

[pluto via Wien]

Dear Prof. Blaha,

Thank you for your comments.

Are the functions u and u-dot provided in some output file? Manual 
mentions different types of u and u-dot for the cases of Psi^LO and 
Psi^lo. Manual also mentions that u and u-dot are obtained by numerical 
integration of radial Schrodinger equation on the mesh. Are they all 
tabulated somewhere?


Having all the A_lm, B_lm, C_lm and all the u and u-dot would allow to 
have the full wave function Psi(r) inside the spheres as a function of 
wave-vector and energy. That would allow to numerically calculate the 
matrix elements which I need, with the assumption of my favorite final 
state, and without any further assumptions. The only remaining problem 
would be the interstitial region, but it would also be under control by 
knowing how much charge leaks out of the spheres.


Best,
Lukasz




On 2023-02-09 18:06, Peter Blaha wrote:
Well, I'm not sure I do understand all your problems, but a few 
comments:


a) XMCD is implemented in   optics !

b) I do not see the problem with A_lm, B_lm C_lm,..., because in any
case  A_lm (or for semicore a C_lm) will dominate and you can probably
neglect the B_lm and the corresponding u-dot radial function.

When you chose a good expansion energy for your radial wf., you more
or less have this "hydrogenic orbital" with one fixed radial function.
Of course, this argument holds only when your states are "localized",
otherwise you will have a large interstital (PW) contribution.

c) I'm not the real expert of Wannier functions, but I guess the WF
might be complicated linear combinations of different l,m 



Am 09.02.2023 um 15:46 schrieb pluto via Wien:

Dear Sylwia, dear Prof. Blaha, dear All,

Having these A_lm, B_lm etc is of course a problem if one wants to 
estimate interferences in dipole optical matrix element due to phases 
at which different Y_lm orbitals enter the wave function. It would be 
good to have a single complex number per Y_lm.


For this it would be good to have the LAPW wavefunction projected onto 
hydrogenic orbitals that just have a single radial component. Then 
there would be just one complex coefficient. For a particular l (i.e. 
s, p, or d) one would have a common radial part of the wave function, 
since the radial part does not depend on m. Then one would need to 
assume the final state expansion in Y_lm (can always be done even for 
free-electron final state) and do some estimation of the XMCD process 
within the simplified LCAO way of thinking.


Is there any tool already existing to project WIEN2k wave function 
onto hydrogenic orbitals?
I was thinking something like this might be a part of the 
WIEN2Wannier, but I wanted to ask here before investing further time 
into this.


Best,
Lukasz



___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] QTL quantization axis for Y_lm orbitals

[pluto via Wien]

Dear Sylwia, dear Prof. Blaha, dear All,

Having these A_lm, B_lm etc is of course a problem if one wants to 
estimate interferences in dipole optical matrix element due to phases at 
which different Y_lm orbitals enter the wave function. It would be good 
to have a single complex number per Y_lm.


For this it would be good to have the LAPW wavefunction projected onto 
hydrogenic orbitals that just have a single radial component. Then there 
would be just one complex coefficient. For a particular l (i.e. s, p, or 
d) one would have a common radial part of the wave function, since the 
radial part does not depend on m. Then one would need to assume the 
final state expansion in Y_lm (can always be done even for free-electron 
final state) and do some estimation of the XMCD process within the 
simplified LCAO way of thinking.


Is there any tool already existing to project WIEN2k wave function onto 
hydrogenic orbitals?
I was thinking something like this might be a part of the WIEN2Wannier, 
but I wanted to ask here before investing further time into this.


Best,
Lukasz


--
PD Dr. Lukasz Plucinski
Group Leader, FZJ PGI-6
Phone: +49 2461 61 6684
https://electronic-structure.fz-juelich.de/



 Original Message 
Subject: Re: [Wien] QTL quantization axis for Y_lm orbitals
Date: 2023-01-17 20:02
From: gutow...@agh.edu.pl
To: A Mailing list for WIEN2k users 
Reply-To: A Mailing list for WIEN2k users 



Dear Lukasz,

the reason is that the (radial part) of the wave function is actually 
the sum of 5 terms.
As mentioned at http://www.wien2k.at/lapw/index.html in sector 
"LAPW+LO", the wave function is the sum of the atomic radial wave 
function and its energy derivative multiplied by the factors A_lm(k) and 
B_lm(k) respectively.
There is also an additional radial wave function called the local 
orbital with the coefficient C_lm(k).
Then comes the APW+lo method, where the local orbital is the sum of the 
new radial wave function and its energy derivative multiplied by the new 
coefficients A'_lm(k) and B'_lm(k), respectively.
This gives 5 coefficients: A_lm(k), B_lm(k), C_lm(k), A'_lm(k), B'_lm(k) 
in the case.almblm file. Each of them has a real and an imaginary part.

This is explained in Chapter 2 of the User's Guide.

what's best
Sylwia
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] qtl printed output issue

[pluto via Wien]

Dear All,

When running "x qtl" I am getting an error message printed in Wien 23.1 
edition, see below. I tested this in couple of different test cases, 
with and without FM and SOC, always the same error.


It seems this error message does not affect anything. The case.qtl file 
is created, and I can use "spaghetti" and "plot bandstructure" to plot 
the "fat bands" in w2web and everything looks fine.


Can I ignore the error?

bash-5.1$ x qtl -up -so
FERMI - Error
0.015u 0.003s 0:00.01 100.0%0+0k 0+552io 0pf+0w
 QTL END
28.708u 0.507s 0:08.70 335.6%   0+0k 0+53792io 13pf+0w

Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] run_lapw

[pluto via Wien]

Dear Prof. Blaha,

I understand it is enough to simply replace the existing run_lapw file?

Or does one need to recompile everything?

Best,
Lukasz



On 2023-02-01 12:43, Peter Blaha wrote:

Only 23.

Am 01.02.2023 um 12:09 schrieb Laurence Marks:

Which version(s) of Wien2k does this effect?

--
Professor Laurence Marks
Department of Materials Science and Engineering, Northwestern 
University

www.numis.northwestern.edu 
"Research is to see what everybody else has seen, and to think what 
nobody else has thought" Albert Szent-Györgyi


On Wed, Feb 1, 2023, 02:31 Peter Blaha > wrote:


Dear wien2k users,

There is a small bug in  run_lapw for cases without inversion 
symmetry.
Most likely not critical except when the default case.in1c file 
would

produce a QTL-B error, which would not be fixed automatically.

A new version is attached and the web-version has been corrected
(release 1.2.23)

Regards
-- 
--

Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.bl...@tuwien.ac.at   
 WIEN2k: http://www.wien2k.at 

WWW: http://www.imc.tuwien.ac.at 

-___

Wien mailing list
Wien@zeus.theochem.tuwien.ac.at 


http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

SEARCH the MAILING-LIST at:

http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html 




___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] QTL quantization axis for Y_lm orbitals

[pluto via Wien]

calculated only from contributions inside spheres will be incomplete 
(the LAPW-basis is NOT a LCAO-basis set !!!), though when interested in 
localized 3d (4f) electrons it could be a good approximation.


c) Be aware that what you get from qtl are "symmetrized" partial 
charges, i.e. the qtl's are averaged over the equivalent k-points in 
the full BZ. Note that the A_lm(k=100) are in general different from 
A_lm(k=010), even in a tetragonal symmetry, where we usually have only 
k=100 in the mesh, but not k=010.


So you probably have to calculate a full k-mesh and sum externally over 
the equivalent k-points.




Thank you for the quick answer.

I am thinking more of a circular dichroism in photoemission, intuitive 
approximate orbital-resolved description in some simple cases. For 
this one needs the quantization axis (the z-axis) along the incoming 
light (this is possible in QTL, as we discussed in previous emails) 
and the phases of the coefficients (which, it seems, are not 
printed-out by QTL).


I will look into -alm option, thank you for letting me know this 
option. As I understand, lapw2 projects orbitals only according to the 
coordinate system defined by case.struct file. So I would need to 
rotate the coordinate frame to get the new z-axis along the 
experimental light direction (I think might be tedious but quite 
elementary, I think this is what QTL does).


Best,
Lukasz



On 2023-01-16 18:38, Peter Blaha wrote:

Hi,
In lapw2 there is an input option ALM (use   x lapw2 -alm), which
would write the A_lm, B_lm, as well as the radial wf. into a file.

optical matrix elements: They are calculated anyway in optics.

Regards

Am 16.01.2023 um 17:13 schrieb pluto via Wien:

Dear Prof Blaha, dear All,

I think QTL provides squared wave function coefficients, which are 
real numbers. Can we get the complex coefficients, before squaring? 
The phase might matter in some properties, such as optical matrix 
elements.


I explain in more detail. We can assume some Psi = A|s> + B|p>. 
Using QTL we will get |A|^2 and |B|^2, and we can plot these to e.g. 
get the "fat bands", i.e. the orbital character of the bands. But in 
general A and B are complex numbers, can we output them before they 
are squared?


Best,
Lukasz






On 22/12/2022 18:12, Peter Blaha wrote:

Subject:
Re: [Wien] QTL quantization axis for Y_lm orbitals
From:
Peter Blaha 
Date:
22/12/2022, 18:12
To:
wien@zeus.theochem.tuwien.ac.at

Hi,
In your example with (1. 0. 0.) it means that what is plotted in 
the partial charges (or partial DOS) as pz, points into the 
crystallographic x-axis (I guess it interchanges px and pz). I'm 
not sure if such a rotation would ever be necessary.


In your input file you have (1. 1. 1.), which means that pz will 
point into the 111 direction of the crystal.  This could be a real 
and meaningful choice.


Such lroc make sense to exploit "approximate" symmetries of eg. of 
a distorted (and tilted) octahedron, where you want the z-axis to 
be in the shortest Me-O direction.


> PS: where can I find the "QTL - technical report by P. Novak"? I don't
> see it on WIEN2k website.

This pdf file is in SRC_qtl.

Regards
Peter Blaha

Am 22.12.2022 um 17:52 schrieb pluto via Wien:

Dear All,

I would like to calculate orbital projections for the Y_lm basis 
(spherical harmonics) along some generic quantization axis using 
QTL program.


Below I paste an exanple case.inq input file from the manual (page 
206). When "loro" is set to 1 one can set a "new axis z".


Is that axis the new quantization axis for the Y_lm orbitals? I 
just want to make sure.


This would mean that if I set the "new axis" to 1. 0. 0., I will 
have the basis of |pz+ipy>, |px>, and |pz-ipy>. It that correct?


Best,
Lukasz

PS: where can I find the "QTL - technical report by P. Novak"? I 
don't see it on WIEN2k website.




-- top of file: case.inq 
-7. 2. Emin Emax
2 number of selected atoms
1 2 0 0 iatom1 qsplit1 symmetrize loro
2 1 2 nL1 p d
3 3 1 1 iatom2 qsplit2 symmetrize loro
4 0 1 2 3 nL2 s p d f
1. 1. 1. new axis z
--- bottom of file 

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] QTL quantization axis for Y_lm orbitals

[pluto via Wien]

Dear Prof. Blaha,

Thank you for the quick answer.

I am thinking more of a circular dichroism in photoemission, intuitive 
approximate orbital-resolved description in some simple cases. For this 
one needs the quantization axis (the z-axis) along the incoming light 
(this is possible in QTL, as we discussed in previous emails) and the 
phases of the coefficients (which, it seems, are not printed-out by 
QTL).


I will look into -alm option, thank you for letting me know this option. 
As I understand, lapw2 projects orbitals only according to the 
coordinate system defined by case.struct file. So I would need to rotate 
the coordinate frame to get the new z-axis along the experimental light 
direction (I think might be tedious but quite elementary, I think this 
is what QTL does).


Best,
Lukasz



On 2023-01-16 18:38, Peter Blaha wrote:

Hi,
In lapw2 there is an input option ALM (use   x lapw2 -alm), which
would write the A_lm, B_lm, as well as the radial wf. into a file.

optical matrix elements: They are calculated anyway in optics.

Regards

Am 16.01.2023 um 17:13 schrieb pluto via Wien:

Dear Prof Blaha, dear All,

I think QTL provides squared wave function coefficients, which are 
real numbers. Can we get the complex coefficients, before squaring? 
The phase might matter in some properties, such as optical matrix 
elements.


I explain in more detail. We can assume some Psi = A|s> + B|p>. Using 
QTL we will get |A|^2 and |B|^2, and we can plot these to e.g. get the 
"fat bands", i.e. the orbital character of the bands. But in general A 
and B are complex numbers, can we output them before they are squared?


Best,
Lukasz






On 22/12/2022 18:12, Peter Blaha wrote:

Subject:
Re: [Wien] QTL quantization axis for Y_lm orbitals
From:
Peter Blaha 
Date:
22/12/2022, 18:12
To:
wien@zeus.theochem.tuwien.ac.at

Hi,
In your example with (1. 0. 0.) it means that what is plotted in the 
partial charges (or partial DOS) as pz, points into the 
crystallographic x-axis (I guess it interchanges px and pz). I'm not 
sure if such a rotation would ever be necessary.


In your input file you have (1. 1. 1.), which means that pz will 
point into the 111 direction of the crystal.  This could be a real 
and meaningful choice.


Such lroc make sense to exploit "approximate" symmetries of eg. of a 
distorted (and tilted) octahedron, where you want the z-axis to be in 
the shortest Me-O direction.


> PS: where can I find the "QTL - technical report by P. Novak"? I don't
> see it on WIEN2k website.

This pdf file is in SRC_qtl.

Regards
Peter Blaha

Am 22.12.2022 um 17:52 schrieb pluto via Wien:

Dear All,

I would like to calculate orbital projections for the Y_lm basis 
(spherical harmonics) along some generic quantization axis using QTL 
program.


Below I paste an exanple case.inq input file from the manual (page 
206). When "loro" is set to 1 one can set a "new axis z".


Is that axis the new quantization axis for the Y_lm orbitals? I just 
want to make sure.


This would mean that if I set the "new axis" to 1. 0. 0., I will 
have the basis of |pz+ipy>, |px>, and |pz-ipy>. It that correct?


Best,
Lukasz

PS: where can I find the "QTL - technical report by P. Novak"? I 
don't see it on WIEN2k website.




-- top of file: case.inq 
-7. 2. Emin Emax
2 number of selected atoms
1 2 0 0 iatom1 qsplit1 symmetrize loro
2 1 2 nL1 p d
3 3 1 1 iatom2 qsplit2 symmetrize loro
4 0 1 2 3 nL2 s p d f
1. 1. 1. new axis z
--- bottom of file 
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at: 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html


--
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.bl...@tuwien.ac.at    WIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at
-
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at: 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html



___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] QTL quantization axis for Y_lm orbitals

[pluto via Wien]

Dear Prof Blaha, dear All,

I think QTL provides squared wave function coefficients, which are real 
numbers. Can we get the complex coefficients, before squaring? The phase 
might matter in some properties, such as optical matrix elements.


I explain in more detail. We can assume some Psi = A|s> + B|p>. Using 
QTL we will get |A|^2 and |B|^2, and we can plot these to e.g. get the 
"fat bands", i.e. the orbital character of the bands. But in general A 
and B are complex numbers, can we output them before they are squared?


Best,
Lukasz






On 22/12/2022 18:12, Peter Blaha wrote:

Subject:
Re: [Wien] QTL quantization axis for Y_lm orbitals
From:
Peter Blaha 
Date:
22/12/2022, 18:12
To:
wien@zeus.theochem.tuwien.ac.at

Hi,
In your example with (1. 0. 0.) it means that what is plotted in the 
partial charges (or partial DOS) as pz, points into the 
crystallographic x-axis (I guess it interchanges px and pz). I'm not 
sure if such a rotation would ever be necessary.


In your input file you have (1. 1. 1.), which means that pz will point 
into the 111 direction of the crystal.  This could be a real and 
meaningful choice.


Such lroc make sense to exploit "approximate" symmetries of eg. of a 
distorted (and tilted) octahedron, where you want the z-axis to be in 
the shortest Me-O direction.


> PS: where can I find the "QTL - technical report by P. Novak"? I don't
> see it on WIEN2k website.

This pdf file is in SRC_qtl.

Regards
Peter Blaha

Am 22.12.2022 um 17:52 schrieb pluto via Wien:

Dear All,

I would like to calculate orbital projections for the Y_lm basis 
(spherical harmonics) along some generic quantization axis using QTL 
program.


Below I paste an exanple case.inq input file from the manual (page 
206). When "loro" is set to 1 one can set a "new axis z".


Is that axis the new quantization axis for the Y_lm orbitals? I just 
want to make sure.


This would mean that if I set the "new axis" to 1. 0. 0., I will have 
the basis of |pz+ipy>, |px>, and |pz-ipy>. It that correct?


Best,
Lukasz

PS: where can I find the "QTL - technical report by P. Novak"? I don't 
see it on WIEN2k website.




-- top of file: case.inq 
-7. 2. Emin Emax
2 number of selected atoms
1 2 0 0 iatom1 qsplit1 symmetrize loro
2 1 2 nL1 p d
3 3 1 1 iatom2 qsplit2 symmetrize loro
4 0 1 2 3 nL2 s p d f
1. 1. 1. new axis z
--- bottom of file 
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html


--
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.bl...@tuwien.ac.atWIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at
-
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html



___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] QTL quantization axis for Y_lm orbitals

[pluto via Wien]

Dear All,

I would like to calculate orbital projections for the Y_lm basis 
(spherical harmonics) along some generic quantization axis using QTL 
program.


Below I paste an exanple case.inq input file from the manual (page 206). 
When "loro" is set to 1 one can set a "new axis z".


Is that axis the new quantization axis for the Y_lm orbitals? I just 
want to make sure.


This would mean that if I set the "new axis" to 1. 0. 0., I will have 
the basis of |pz+ipy>, |px>, and |pz-ipy>. It that correct?


Best,
Lukasz

PS: where can I find the "QTL - technical report by P. Novak"? I don't 
see it on WIEN2k website.




-- top of file: case.inq 
-7. 2. Emin Emax
2 number of selected atoms
1 2 0 0 iatom1 qsplit1 symmetrize loro
2 1 2 nL1 p d
3 3 1 1 iatom2 qsplit2 symmetrize loro
4 0 1 2 3 nL2 s p d f
1. 1. 1. new axis z
--- bottom of file 
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] budget CPU and Linux system for precompiled binaries

[pluto via Wien]

Dear All,

I am considering to build a simple Linux PC for WIEN2k, price range 
between ca. 500-2000 EUR. It would be used to run band-structure 
calculations.


I will run precompiled WIEN2k executables on this. Is there a preferred 
CPU and Linux system that would ensure good compatibility?


I suppose this question is asked quite a lot, but hardware changes 
quickly. Any comments on a particular CPU/mainboard configuration, RAM 
amount, type of SSD etc. would be appreciated.


Best,
Lukasz


--
PD Dr. Lukasz Plucinski
Group Leader, FZJ PGI-6
Phone: +49 2461 61 6684
https://electronic-structure.fz-juelich.de/
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html