Re: [Wien] 'FERMI' - INTEGRATION FAILED lapw2 error

2023-03-15 Thread Tim Williams via Wien
Dear Peter,

Thank you for your prompt reply.

"I've seen this a few times"  — Sorry, I complicated my story unnecessarily. 
Simply, it’s perhaps the same problem each time so if I can find out what’s 
happening in this case (or any) it will apply to all. 
A beginner so I am trying to see what works and why without much in the way of 
worked examples. For guidance I’m simply following the “Lithium ELNES with 
WIEN2K October 12, 2018” which has worked well in most cases, including similar 
supercells. So I am puzzled as to why I get no ELNES in this case.
I don’t have a case.inqtl here. For reference none of my TELNES calculations 
(successful or otherwise) have generated a case.inqtl; I’ve also not found any 
reference to this file searching in the UG. Should I have this file? I do have 
a file case.inq_st, this has a line 16 number of atoms and looks the same as 
case.inqtl referenced in a previous thread you recently commented on. 
What is case.inqtl (or in my situation, case.inq_st), why is there a 25 atom 
limit, and how to set / restrict the number?
STDOUT is blank after running TELNES3 but after the SCF the output was normal, 
as the DAYFILE. Nothing to suggest I would have blank TELNES result anyway.
The structure is defined in P1 as I will add a core hole on a Ti atom. The 
structure is a supercell of anatase. If I don’t intervene the init_lapw will 
revert to high symmetry (16 Ti).
Sorry again for the doubtless stupid questions… On the the hand having access 
to very high resolution experimental EELS data from these materials potentially 
makes the effort worthwhile.
Best,

Tim.









---  
Dr. Tim Williams  
Transmission Electron Microscope Manager

Monash Centre for Electron Microscopy (MCEM)
Monash University 
Room 103, 10 Innovation Walk, Clayton Campus
Wellington Road
Clayton VIC 3800
Australia
T: +61 (0) 3 9902 0721  
M: +61 (0) 401 853 850
e: timothy.willi...@monash.edu

CRICOS Provider: Monash University
8C/01857J
 
We acknowledge and pay respects to the Elders
and Traditional Owners of the land on which our
four Australian campuses stand.

___
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] [SPAM?] Re: illegal character: N in optimize job

2023-03-15 Thread Laurence Marks
Also, the output of Check-mixing is often useful.

On Wed, Mar 15, 2023 at 4:04 PM Peter Blaha 
wrote:

>  > :CHARGE convergence:  0 0.01 94.5554737
>
> Such a large :DIS means that something is wrong.
>
> It could be the starting density for this structure (volume) is very bad
> or some other mistake.
> Did you make a complete scf for some other volume without problems ?
>
> I also do not understand your dayfile.
> In lapw1 there is only one line:
> irene4046 k=68user=0.139  wallclock=446.43
> in lapw2 there are 2 lines ???
>
> What is your .machines file ?
>
> Check:NEC01  and :ENE, :WAR
>
> --
> A first guess to try:
>
> x dstart
> optimize.job
>
>
> Am 15.03.2023 um 20:52 schrieb pboulet:
> > Hello,
> >
> > I am trying to optimize a cubic structure with the version 23.2. At the
> > end of the first step of the SCF (1st structure), I get the following
> error:
> > (standard_in) 1: illegal character: N
> >
> >
> > I wonder if I make a mistake or not. There are old emails (2010-2011) in
> > the mailing-list with similar messages, but they seem to relate to MacOS
> > while I am running the job on a linux supercomputer.
> >
> >
> > The *.error files are all empty.
> >
> > The case.dayfile contains:
> >  start   (Wed Mar 15 18:48:44 CET 2023) with lapw0 (40/99 to go)
> >
> >  cycle 1 (Wed Mar 15 18:48:44 CET 2023)  (40/99 to go)
> >
> >  >   lapw0   -p  (18:48:44) starting parallel lapw0 at Wed Mar
> > 15 18:48:44 CET 2023
> >  .machine0 : 6 processors
> > 0.134u 0.152s 0:12.26 2.2%  0+0k 32+120io 0pf+0w
> >  >   lapw1  -p   -c  (18:48:56) starting parallel lapw1 at Wed Mar
> > 15 18:48:57 CET 2023
> > ->  starting parallel LAPW1 jobs at Wed Mar 15 18:48:57 CET 2023
> > running LAPW1 in parallel mode (using .machines)
> > Summary of lapw1para:
> > irene4046 k=68user=0.139  wallclock=446.43
> > 1.426u 2.104s 4:59.35 1.1%  0+0k 136+496io 1pf+0w
> >  >   lapw2 -p -c (18:53:56) running LAPW2 in parallel mode
> >irene4046 0.082u 0.042s 0:38.98 0.3% 0+0k 0+32io 0pf+0w
> >irene4046 0.064u 0.062s 1:11.18 0.1% 0+0k 8+32io 0pf+0w
> > Summary of lapw2para:
> > irene4046 user=0.146  wallclock=110.16
> > 0.981u 0.592s 1:15.49 2.0%  0+0k 10088+10672io 0pf+0w
> >  >   lcore   (18:55:12) 0.112u 0.032s 0:00.76 18.4%  0+0k 2856+856io
> > 0pf+0w
> >  >   mixer   (18:55:13) 0.099u 0.057s 0:00.78 17.9%  0+0k
> > 4520+8064io 0pf+0w
> > :ENERGY convergence:  0 0.0001 2.02451855
> > :CHARGE convergence:  0 0.01 94.5554737
> >
> >  >   stop error
> >
> > I can see this error in a log file:
> > ERROR status in Cu12Sb4S13_vol0.50
> >
> >
> > There is a ‘tmp1247146’ file present in the directory that contains:
> > 0.0
> >  NaN
> >  NaN
> >  NaN
> > 246361.85088
> >
> >
> > Any hints would be welcome.
> >
> > Thank you
> > Pascal
> >
> >
> >
> > Pascal Boulet
> > —
> > /Professor in computational materials chemistry - DEPARTMENT OF
> CHEMISTRY/
> > University of Aix-Marseille - Avenue Escadrille Normandie Niemen -
> > F-13013 Marseille - FRANCE
> > Tél: +33(0)4 13 55 18 10 - Fax : +33(0)4 13 55 18 50
> > Email : pascal.bou...@univ-amu.fr 
> >
> >
> >
> >
> >
> > ___
> > 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
>


-- 
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
https://scholar.google.com/citations?user=zmHhI9gJ&hl=en

"Research is to see what everybody else has seen, and to think what nobody
else has thought", Albert Szent-Györgyi
___
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] illegal character: N in optimize job

2023-03-15 Thread Peter Blaha

> :CHARGE convergence:  0 0.01 94.5554737

Such a large :DIS means that something is wrong.

It could be the starting density for this structure (volume) is very bad 
or some other mistake.

Did you make a complete scf for some other volume without problems ?

I also do not understand your dayfile.
In lapw1 there is only one line:
irene4046 k=68user=0.139  wallclock=446.43
in lapw2 there are 2 lines ???

What is your .machines file ?

Check:NEC01  and :ENE, :WAR

--
A first guess to try:

x dstart
optimize.job


Am 15.03.2023 um 20:52 schrieb pboulet:

Hello,

I am trying to optimize a cubic structure with the version 23.2. At the 
end of the first step of the SCF (1st structure), I get the following error:

(standard_in) 1: illegal character: N


I wonder if I make a mistake or not. There are old emails (2010-2011) in 
the mailing-list with similar messages, but they seem to relate to MacOS 
while I am running the job on a linux supercomputer.



The *.error files are all empty.

The case.dayfile contains:
     start       (Wed Mar 15 18:48:44 CET 2023) with lapw0 (40/99 to go)

     cycle 1     (Wed Mar 15 18:48:44 CET 2023)  (40/99 to go)

 >   lapw0   -p          (18:48:44) starting parallel lapw0 at Wed Mar 
15 18:48:44 CET 2023

 .machine0 : 6 processors
0.134u 0.152s 0:12.26 2.2%      0+0k 32+120io 0pf+0w
 >   lapw1  -p   -c      (18:48:56) starting parallel lapw1 at Wed Mar 
15 18:48:57 CET 2023

->  starting parallel LAPW1 jobs at Wed Mar 15 18:48:57 CET 2023
running LAPW1 in parallel mode (using .machines)
    Summary of lapw1para:
    irene4046     k=68    user=0.139      wallclock=446.43
1.426u 2.104s 4:59.35 1.1%      0+0k 136+496io 1pf+0w
 >   lapw2 -p     -c     (18:53:56) running LAPW2 in parallel mode
       irene4046 0.082u 0.042s 0:38.98 0.3% 0+0k 0+32io 0pf+0w
       irene4046 0.064u 0.062s 1:11.18 0.1% 0+0k 8+32io 0pf+0w
    Summary of lapw2para:
    irene4046     user=0.146      wallclock=110.16
0.981u 0.592s 1:15.49 2.0%      0+0k 10088+10672io 0pf+0w
 >   lcore       (18:55:12) 0.112u 0.032s 0:00.76 18.4%  0+0k 2856+856io 
0pf+0w
 >   mixer       (18:55:13) 0.099u 0.057s 0:00.78 17.9%  0+0k 
4520+8064io 0pf+0w

:ENERGY convergence:  0 0.0001 2.02451855
:CHARGE convergence:  0 0.01 94.5554737

 >   stop error

I can see this error in a log file:
ERROR status in Cu12Sb4S13_vol0.50


There is a ‘tmp1247146’ file present in the directory that contains:
0.0
             NaN
             NaN
             NaN
    246361.85088


Any hints would be welcome.

Thank you
Pascal



Pascal Boulet
—
/Professor in computational materials chemistry - DEPARTMENT OF CHEMISTRY/
University of Aix-Marseille - Avenue Escadrille Normandie Niemen - 
F-13013 Marseille - FRANCE

Tél: +33(0)4 13 55 18 10 - Fax : +33(0)4 13 55 18 50
Email : pascal.bou...@univ-amu.fr 





___
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] illegal character: N in optimize job

2023-03-15 Thread pboulet
Hello,

I am trying to optimize a cubic structure with the version 23.2. At the end of 
the first step of the SCF (1st structure), I get the following error:
(standard_in) 1: illegal character: N


I wonder if I make a mistake or not. There are old emails (2010-2011) in the 
mailing-list with similar messages, but they seem to relate to MacOS while I am 
running the job on a linux supercomputer.


The *.error files are all empty.

The case.dayfile contains:
start   (Wed Mar 15 18:48:44 CET 2023) with lapw0 (40/99 to go)

cycle 1 (Wed Mar 15 18:48:44 CET 2023)  (40/99 to go)

>   lapw0   -p  (18:48:44) starting parallel lapw0 at Wed Mar 15 
> 18:48:44 CET 2023
 .machine0 : 6 processors
0.134u 0.152s 0:12.26 2.2%  0+0k 32+120io 0pf+0w
>   lapw1  -p   -c  (18:48:56) starting parallel lapw1 at Wed Mar 15 
> 18:48:57 CET 2023
->  starting parallel LAPW1 jobs at Wed Mar 15 18:48:57 CET 2023
running LAPW1 in parallel mode (using .machines)
   Summary of lapw1para:
   irene4046 k=68user=0.139  wallclock=446.43
1.426u 2.104s 4:59.35 1.1%  0+0k 136+496io 1pf+0w
>   lapw2 -p -c (18:53:56) running LAPW2 in parallel mode
  irene4046 0.082u 0.042s 0:38.98 0.3% 0+0k 0+32io 0pf+0w
  irene4046 0.064u 0.062s 1:11.18 0.1% 0+0k 8+32io 0pf+0w
   Summary of lapw2para:
   irene4046 user=0.146  wallclock=110.16
0.981u 0.592s 1:15.49 2.0%  0+0k 10088+10672io 0pf+0w
>   lcore   (18:55:12) 0.112u 0.032s 0:00.76 18.4%  0+0k 2856+856io 0pf+0w
>   mixer   (18:55:13) 0.099u 0.057s 0:00.78 17.9%  0+0k 4520+8064io 0pf+0w
:ENERGY convergence:  0 0.0001 2.02451855
:CHARGE convergence:  0 0.01 94.5554737

>   stop error

I can see this error in a log file:
ERROR status in Cu12Sb4S13_vol0.50


There is a ‘tmp1247146’ file present in the directory that contains:
0.0
NaN
NaN
NaN
   246361.85088


Any hints would be welcome.

Thank you
Pascal



Pascal Boulet
—
Professor in computational materials chemistry - DEPARTMENT OF CHEMISTRY
University of Aix-Marseille - Avenue Escadrille Normandie Niemen - F-13013 
Marseille - FRANCE
Tél: +33(0)4 13 55 18 10 - Fax : +33(0)4 13 55 18 50
Email : pascal.bou...@univ-amu.fr 






smime.p7s
Description: S/MIME cryptographic signature
___
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

2023-03-15 Thread 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] Lu

2023-03-15 Thread Karel Vyborny

Dear Pablo,
just noticed... Have you really been looking into lutetium metal? Is that 
only for the sake of testing your new wien2k compilation or you had any 
deeper interest in it? In fact, I do :)


Kind regards,

Karel


On Tue, 14 Mar 2023, delamora wrote:


Thanks Prof. Marks,

I ran the simple Na BCC and I got
 Cholesky INFO =           87

Then Lu Hex
 Cholesky INFO =          136

also Cu FCC
Cholesky INFO =           28

So there is something wrong. Before I could run Na and Cu without problem.
I am not mixing 17.1 with 23.1, I just want to fix this problem before I go
forward.

Pablo


De: Wien  en nombre de Laurence
Marks 
Enviado: lunes, 13 de marzo de 2023 10:46 p. m.
Para: A Mailing list for WIEN2k users 
Asunto: Re: [Wien] compiling the WIEN2k 23.1 version  
This is 95% not an indication of something wrong with your computer. The
error is indicating that the 87th row/column of your Hamiltonian is too
similar to another, so the Cholesky decomposition is failing. This most
often occurs if you have a mistake in your case.in1 file, where some of the
linearization energies are too close. If you have a bad potential (density)
I think it can also occur.

However, without more information it is hard to guess more. Perhaps save the
version that went wrong and recreate it. It may not be safe to mix an old
17.1 version and 23.1, as some formats have changed.

--
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 Mon, Mar 13, 2023, 23:33 delamora  wrote:
  Prof Blaha,
Thank for your reply
When I ran the "siteconfig" it would run without stoping not allowing
me to compile the program, but now it does stop and it allows me to
compile

But there is something wrong in my computer in the earlier 17.1
version
I try to run a system and it stops just after LAPW0;
--
[pablo@delamora Na-prueb]$ run  LAPW0 END
SECLR4 - Error
grep: lapw2*.error: No such file or directory

>   stop error
[pablo@delamora Na-prueb]$ more lapw1.error
 Cholesky INFO =           87
 'SECLR4' - POTRF (Scalapack/LAPACK) failed.
[pablo@delamora Na-prueb]$
--
So what are these errors? It seems that
Scalapack/LAPACK
has been corrupted

Pablo


De: Wien  en nombre de Peter
Blaha 
Enviado: martes, 7 de marzo de 2023 06:13 a. m.
Para: wien@zeus.theochem.tuwien.ac.at

Asunto: Re: [Wien] compiling the WIEN2k 23.1 version  
> I downloaded the WIEN2k 23.1 version
> I followed the instructions
>
> ..
>
> ./expand_lapw
>
> .siteconfig_lapw -update ../WIEN2k-21.1/
>
> but I did not compile it
> so I restarted the procedure from the begining and when I came to
this
> last command
>
> .siteconfig_lapw -update ../WIEN2k-21.1/
>
> it was executed in one step, but I could not compile the program
> So my question is how I compile it

?
You should come into the main menue of siteconfig. Then just press
R  (compile/recompile).

Make sure that   ../WIEN2k-21.1   still contains proper WIEN2k_*
configuration files.

>
> Pablo
>
> ___
> 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] Difference between "x lapw2 -qtl" and "x qtl"

2023-03-15 Thread 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 of 
magnetization)

  30   numbe

Re: [Wien] 'FERMI' - INTEGRATION FAILED lapw2 error

2023-03-15 Thread Peter Blaha

Same thing as before: Maybe you hit the limit of 25 atoms in case.inqtl.

"I've seen this a few times"  does not help me. Pin down the problem and 
report it specifically (or include the struct file) so that we can 
reproduce it.


Otherwise:

Why do you run in P1 ???

When running in w2web, please always check the STDOUT on the screen to 
see if a command run properly or not. Very often one reports the error 
that the "plot" does not appear, but the actual error is in a couple of 
steps before and has been overlooked or ignored.



Am 15.03.2023 um 02:05 schrieb Tim Williams via Wien:
Thank you for your advice Peter, my error was incorrectly edited 
machines file. When corrected the calculation converged.


I have another (actually, recurring) problem running TELNES (using the 
W2Web interface). I often have *no ELNES output (zeros) *despite 
converged SCF. All error files empty. My case.innes is same as I use for 
all TELNES (including successful results).


The structure is simply TiO2 anatase with a 3x3x2 supercell, no symmetry 
(P1), in this case no core-hole added yet. I used TEMP 0.002 instead of 
TETRA, SINGLE mode SCF, and the DOS calculation works fine (plotting 
DOS). Only TELNES seems to be null.


I’ve seen this null ELNES output quite a few times (not only SINGLE mode 
SCF / supercells) but can’t pin down what it the cause (or causes). 
Clearly something in the SCF starting parameters? In initlpw I didn’t 
accept the new case.struct as the symmetry had been changed so it’s P1 
non-centrosymmetric. Where is my ELNES?


Ideas please!!

Best,

Tim.
---
Dr. Tim Williams

Monash Centre for Electron Microscopy (MCEM)
Monash University
Clayton VIC 3800
Australia
/
/
/case.struct (in part):/

*anatase 332*
*P   LATTICE,NONEQUIV.ATOMS:216 1_P1*
*MODE OF CALC=RELA unit=bohr*
* 21.454061 21.454061 35.959599 90.00 90.00 90.00*
*ATOM  -1: X=0. Y=0. Z=0.*
*          MULT= 1          ISPLIT= 8*
*Ti1        NPT=  781  R0=0.5000 RMT=    1.9100   Z: 22.000*
*LOCAL ROT MATRIX:    1.000 0.000 0.000*
*                     0.000 1.000 0.000*
*                     0.000 0.000 1.000*
*… etc etc.*
*
*
*ATOM-216: X=0.6700 Y=0.6700 Z=0.89595000*
*          MULT= 1          ISPLIT= 8*
*O          NPT=  781  R0=0.0001 RMT=    1.7300   Z:  8.000*
*LOCAL ROT MATRIX:    1.000 0.000 0.000*
*                     0.000 1.000 0.000*
*                     0.000 0.000 1.000*
*   1      NUMBER OF SYMMETRY OPERATIONS*
* 1 0 0 0.*
* 0 1 0 0.*
* 0 0 1 0.*
        1

/case.innes:/

*mcem-admin@MU0019202:~/wien2k/Data/anatase332$ cat anatase332.innes*
*Ti1 no core hole *
*1*
*2 1*
*450.00*
*200*
*0. 15. 0.0500*
*5.00 1.87*
*5 2*
*0.50*
*DETECTOR POSITION*
*0.000 0.000*
*MODUS*
*energy*
*SELECTION RULE*
*n*
*LSELECTION RULE*
*d*
*INITIALIZATION*
*y y*
*y y*
*RELATIVISTIC*
*1 *
*QGRID*
*U*
*END*

/case.elnes (part):/

*### The averaged spectrum.*
*## Parameters of the calculation :*
*# Atom   1,  1edge   n= 2 l= 1*
*# Edge onset  450.0 eV;  split   5.77 eV*
*# Beam energy         200. keV*
*# Detector position ThetaX   0.00 ThetaY   0.00  mrad*
*# Selection rules n  d*
*# Collection semiangle   5.00 Convergence semiangle   1.87  mrad*
*# NR   5 NT   2*
*
*
* ##  Energy, spectrum, partial spectrum 1, partial spectrum 2.*
*  -0.05000   0.0E+00   0.0E+00   0.0E+00*
*   0.0   0.0E+00   0.0E+00   0.0E+00*
*   0.05000   0.0E+00   0.0E+00   0.0E+00*
*… etc*
*   1.75000   0.0E+00   0.0E+00   0.0E+00*
*   1.8   0.0E+00   0.0E+00   0.0E+00*
*   1.85000   0.0E+00   0.0E+00   0.0E+00*




___
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


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

2023-03-15 Thread Peter Blaha

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 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 a