Dear Prof. Blaha,
Thank you for the comment.
In my case qtl uses 100% %CPU in top. For speedup I typically run qtl -p
up/dn simultaneously -- see the screenshot from "top" pasted below. I
don't think OMP helps, my global setting is OMP=2.
I think "qtl -p -band" is able to glue the k-parallel results of the
previous "lapw1 -band" (or "lapwso -band") run. But I always thought qtl
is running in a serial mode. I think qtl does it's job k-point by
k-point, so for k-parallel run it would need to look at the .machines
file and run several instances -- this clearly does not happen, qtl
definitely does not use the .machines file for distributing jobs, it
does not run on machines defined in .machines file.
Best,
Lukasz
For the screenshot below I run two instances simultaneously: "qtl -p
-up" and "qtl -p -dn"
top - 21:57:32 up 6 days, 7:14, 4 users, load average: 2.20, 2.60,
2.90
Tasks: 517 total, 3 running, 514 sleeping, 0 stopped, 0 zombie
%Cpu(s): 6.1 us, 0.2 sy, 0.0 ni, 93.7 id, 0.0 wa, 0.0 hi, 0.0 si,
0.0 st
MiB Mem : 47656.5 total, 432.5 free, 3736.8 used, 44354.1
buff/cache
MiB Swap: 16384.0 total, 16296.2 free, 87.8 used. 43919.7 avail
Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
511888 lplucin 20 0 1242220 560380 12032 R 100.0 1.1 54:21.59
qtl
511702 lplucin 20 0 1242220 563996 12032 R 99.7 1.2 55:18.22
qtl
511723 lplucin 20 0 235520 4352 3328 R 0.3 0.0 0:06.63
top
1 root 20 0 174936 16800 10204 S 0.0 0.0 0:15.81
systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:01.34
kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00
rcu_gp
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00
rcu_par_gp
...
On 2024-10-26 21:24, Peter Blaha wrote:
The qtl program already runs in k-parallel mode ....
Am 25.10.2024 um 12:05 schrieb pluto via Wien:
Dear Prof. Blaha,
It would be very helpful to have a k-parallel version of the qtl
program.
With large meshes (I find 51x51 k-points useful in many cases) the qtl
calculation in the slab takes "forever". Of course I can split the
mesh by hand, but a built-in splitting and re-gluing would be
extremely convenient.
Best,
Lukasz
On 2024-10-15 15:56, Peter Blaha wrote:
I can confirm the problems of x qtl -so -band
i) it has a problem with the automatic x lapw2 -fermi
ii) it requires case.in1c (even when inversion is present).
The pragmatic way is to i) neglect the lapw2 FERMI error and to ii)
copy case.in1 to case.in1c (as was done by some users). This produces
correct results.
The proper way is to edit and modify x_lapw.
Search for qtl: You should see the lines as below and
modify/insert as indicated:
case qtl:
if ($?make_inq) then #Kevin Jorissen, for use with telnes3
write_inq_lapw
endif
#we need lapw2 -fermi mandatory, unless -band is specified
#<-update
if( ! $?band ) then
#<-insert
if( "$para" == "para" ) then
x lapw2 -p -fermi $soqtl $updnqtl $hfqtl $band2
else
x lapw2 -fermi $soqtl $updnqtl $hfqtl $band2
endif
endif
#<-insert
set exe = $command$para
...
...
end
if ($cmplx1 == c ) then
#<-update
echo " 7,'$file.in1c', 'unknown', 'formatted',-1">>$def
endif
breaksw
...
Am 14.10.2024 um 10:41 schrieb pluto via Wien:
Dear Yichen,
x qtl is calculating properties for the first equivalent atom of the
case.struct. This means it will give you the "hidden spin
polarization" even if there are equivalent atoms. lapw2 will average
over all equivalent atoms, you will need to disconnect atoms in
case.struct (this means much bigger calculation).
If the energy range in case.inq is small (to reduce the case.qtl
file size), then the x spaghetti may not work for fat bands -- you
need to plot case.qtl manually.
Sometimes the qtl program complains about FERMI. Also, sometimes it
complains about not having case.in1c and/or case.in2c files -- I
think it it OK to copy them from case.in1 and case.in2, maybe Prof.
Blaha can comment.
Also, several weeks ago Prof. Blaha mentioned that one is allowed to
change the order of equivalent atoms in case.struct (I did not test
it yet). This way you can choose which atom is calculated by qtl (if
it didn't happen to be the fist equivalent atom in the original
case.struct).
qtl indeed allows you to set the quantization axis for orbitals
(which typically you want to be 001 for the out-of-plane axis). This
is most of the time really needed, because of all the loc-rots in
the case.struct.
Best,
Lukasz
PS: Keep in mind that atomic the rules for angular intensity
profiles in ARPES are not strict because of multiple scattering.
Furthermore, even the atomic profiles with the proper scattering
state are also not as trivial as the ones derived with FEFS (see Ch.
Fadley papers from around 1980).
On 2024-10-14 10:04, Yichen Zhang wrote:
Dear Peter,
1) No, I’m using version 23.2, so not the latest version. I can
check
with 24.1 on a local cluster which I recently compiled on. I
haven’t
upgraded to 24.1 on my PC, as making it work on a non-intel Mac PC
requires minor modifications to some tcsh and code. I will have to
see
what errors 24.1 will give me on PC. I noticed that in the history
of
upgrading in 23.2 and 24.1, both says x qtl -band has the switch
added
in lapw2 -fermi step.
2) The :log file records,
Sun Oct 13 22:23:46 CDT 2024> (x) qtl -p -so -band
Sun Oct 13 22:23:46 CDT 2024> (x) lapw2 -p -fermi -so -band
So yes, the lapw2 -fermi step has the -band option propagated.
Despite the ‘FERMI” error reported in lapw2.error, qtl successfully
provided reasonable case.qtl result.
3) It would be good to see other testings. If others show
consistent
results, either I made mistakes I was not able to reveal here or it
might be related with the orthorhombicity? I don’t know. I guess we
will see.
Thank you and best regards
Yichen
_______________________________________________
Wien mailing list
[email protected]
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/[email protected]/index.html
_______________________________________________
Wien mailing list
[email protected]
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at: http://www.mail-archive.com/
[email protected]/index.html
_______________________________________________
Wien mailing list
[email protected]
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at: http://www.mail-archive.com/
[email protected]/index.html
_______________________________________________
Wien mailing list
[email protected]
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/[email protected]/index.html
