[Wien] qtl: error reading parallel vectors
Gavin Abo
gsabo at crimson.ua.edu
Wed Oct 21 07:02:01 CEST 2020
I'm not sure about the physics of the following WIEN2k 19.2 parallel
calculation (with all patches at [1] applied), but mechanically the "x
qtl -p -telnes" seems to have run without error.
I typically have SCRATCH in my .bashrc set to "./" but used another
location "/home/username/wiendata/scratch" as seen below. Does a simple
k-point parallel calculation like the one below work on your system? I
haven't tried mpi parallel yet. On the other hand, I have noticed a
possible issue that if one forgets to setup a .machines file and tries
to run a parallel calculation that qtlpara_lapw seems to fail switching
over to the serial calculation mode as shown under [2] below. If one
compares for example lapw2para_lapw and qtlpara_lapw, as illustrated by
[3] below, the qtlpara_lapw may be missing some additional code that
could be needed to get that to work.
username at computername:~/wiendata/diamond$ grep SCRATCH ~/.bashrc
export SCRATCH=/home/username/wiendata/scratch
username at computername:~/wiendata/diamond$ ls
diamond.struct
username at computername:~/wiendata/diamond$ init_lapw -b
...
init_lapw finished ok
username at computername:~/wiendata/diamond$ cat .machines
1:localhost
1:localhost
granularity:1
extrafine:1
username at computername:~/wiendata/diamond$ run_lapw -p
...
in cycle 11 ETEST: .0001457550000000 CTEST: .0033029
hup: Command not found.
STOP LAPW0 END
STOP LAPW1 END
STOP LAPW1 END
STOP LAPW2 - FERMI; weights written
STOP LAPW2 END
STOP LAPW2 END
STOP SUMPARA END
STOP CORE END
STOP MIXER END
ec cc and fc_conv 1 1 1
> stop
username at computername:~/wiendata/diamond$ cp
$WIENROOT/SRC_templates/case.innes diamond.innes
username at computername:~/wiendata/diamond$ x qtl -p -telnes
running QTL in parallel mode
calculating QTL's from parallel vectors
STOP QTL END
6.4u 0.1s 0:06.59 100.0% 0+0k 0+8024io 0pf+0w
username at computername:~/wiendata/diamond$ cat diamond.inq
0 2.20000000000000000000
1
1 99 1 0
4 0 1 2 3
username at computername:~/wiendata/diamond$ x telnes3
STOP TELNES3 DONE
3.3u 0.0s 0:03.39 99.7% 0+0k 0+96io 0pf+0w
[1] https://github.com/gsabo/WIEN2k-Patches/tree/master/19.2
[2] Error when qtlpara_lapw tries to switch to single mode during "x qtl
-p -telnes":
username at computername:~/wiendata/diamond$ cat .machine
cat: .machine: No such file or directory
username at computername:~/wiendata/diamond$ run_lapw -p
...
in cycle 11 ETEST: .0001457550000000 CTEST: .0033029
hup: Command not found.
STOP LAPW0 END
STOP LAPW1 END
STOP LAPW2 END
STOP CORE END
STOP MIXER END
ec cc and fc_conv 1 1 1
> stop
username at computername:~/wiendata/diamond$ cp
$WIENROOT/SRC_templates/case.innes diamond.innes
username at computername:~/wiendata/diamond$ x qtl -p -telnes
single: label not found.
0.0u 0.0s 0:00.01 0.0% 0+0k 0+0io 0pf+0w
error: command /home/username/WIEN2k/qtlpara qtl.def failed
[3] Grep difference between qtlpara_lapw and lapw2para_lapw:
username at computername:~/wiendata/diamond$ grep "single"
$WIENROOT/qtlpara_lapw
testinput .processes single
username at computername:~/wiendata/diamond$ grep "single"
$WIENROOT/lapw2para_lapw
testinput .processes single
single:
echo "running in single mode"
On 10/20/2020 12:24 PM, Christian Søndergaard Pedersen wrote:
>
> Greetings
>
>
> I am trying to run qtl in order to calculate the partial charge
> densities for the telnes3 program. The following fails, generating the
> error in the subject line:
>
>
> run_lapw -p
>
> x qtl -p -telnes
>
>
> Meanwhile, the following works:
>
>
> run_lapw -p
>
> x lapw2 -p -qtl
>
>
> However, lapw2 does not generate the terms necessary for telnes3,
> which subsequently fails with error message "isplit needs to be 99".
>
> From reading this thread:
>
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg05792.html
> <https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg05792.html>
>
>
> ... I understand that it may be related to $SCRATCH. When I look
> inside lapw1.def and lapw2.def, I find:
>
>
> 10,'/scratch/chrsop/case.vector', 'unknown','unformatted',9000
>
>
> ... while qtl.def contains the following:
>
>
> 9,'/scratch/chrsop/case.vector', 'unknown','unformatted',9000
> 10,'/scratch/chrsop/case.vectordn', 'unknown','unformatted',9000
>
>
> Note that lapw1 and lapw2 run smoothly. Presumably, qtl goes looking
> for case.vectordn, which is not generated during run_lapw. I tried
> deleting the offending line in qtl.def and running:
>
>
> x lapw1 -p
>
> x qtl -p -telnes
>
>
> ... but this failed for the same reason as before, and when the job
> finished, qtl.def once again had line 10 as shown above. My case.inq
> file looks like:
>
>
> 0 8.73846153846153846153
> 1
> 1 99 1 0
> 4 0 1 2 3
>
> Any help in solving this matter would be greatly appreciated.
>
>
> Best regards
>
> Christian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20201020/06eefe55/attachment.htm>
-------------- next part --------------
diamond
F LATTICE,NONEQUIV.ATOMS: 1 227_Fd-3m
MODE OF CALC=RELA unit=ang
6.740259 6.740259 6.740259 90.000000 90.000000 90.000000
ATOM 1: X=0.87500000 Y=0.87500000 Z=0.87500000
MULT= 2 ISPLIT= 2
1: X=0.12500000 Y=0.12500000 Z=0.12500000
C NPT= 781 R0=0.00010000 RMT= 1.4200 Z: 6.000
LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000
0.0000000 1.0000000 0.0000000
0.0000000 0.0000000 1.0000000
48 NUMBER OF SYMMETRY OPERATIONS
-1 0 0-0.00000000
0-1 0-0.00000000
0 0-1-0.00000000
1
-1 0 0-0.00000000
0 0-1-0.00000000
0-1 0-0.00000000
2
0-1 0-0.00000000
-1 0 0-0.00000000
0 0-1-0.00000000
3
0 0-1-0.00000000
-1 0 0-0.00000000
0-1 0-0.00000000
4
0-1 0-0.00000000
0 0-1-0.00000000
-1 0 0-0.00000000
5
0 0-1-0.00000000
0-1 0-0.00000000
-1 0 0-0.00000000
6
0 0 1 0.00000000
0 1 0 0.00000000
1 0 0 0.00000000
7
0 1 0 0.00000000
0 0 1 0.00000000
1 0 0 0.00000000
8
0 0 1 0.00000000
1 0 0 0.00000000
0 1 0 0.00000000
9
0 1 0 0.00000000
1 0 0 0.00000000
0 0 1 0.00000000
10
1 0 0 0.00000000
0 0 1 0.00000000
0 1 0 0.00000000
11
1 0 0 0.00000000
0 1 0 0.00000000
0 0 1 0.00000000
12
-1 0 0-0.00000000
0 1 0 0.75000000
0 0 1 0.75000000
13
1 0 0 0.00000000
0-1 0 0.25000000
0 0-1 0.25000000
14
0-1 0 0.25000000
1 0 0 0.00000000
0 0-1 0.25000000
15
1 0 0 0.00000000
0 0-1 0.25000000
0-1 0 0.25000000
16
0 0-1 0.25000000
1 0 0 0.00000000
0-1 0 0.25000000
17
1 0 0 0.75000000
0 1 0 0.75000000
0 0-1-0.00000000
18
-1 0 0 0.25000000
0 1 0 0.00000000
0 0-1 0.25000000
19
1 0 0 0.75000000
0 0 1 0.75000000
0-1 0-0.00000000
20
-1 0 0 0.25000000
0 0 1 0.00000000
0-1 0 0.25000000
21
0 1 0 0.00000000
-1 0 0 0.25000000
0 0-1 0.25000000
22
0 0 1 0.00000000
-1 0 0 0.25000000
0-1 0 0.25000000
23
0-1 0 0.25000000
0 0-1 0.25000000
1 0 0 0.00000000
24
0 0-1 0.25000000
0-1 0 0.25000000
1 0 0 0.00000000
25
0 0 1 0.75000000
0 1 0 0.75000000
-1 0 0-0.00000000
26
0 1 0 0.75000000
0 0 1 0.75000000
-1 0 0-0.00000000
27
0 1 0 0.75000000
1 0 0 0.75000000
0 0-1-0.00000000
28
0 0 1 0.75000000
1 0 0 0.75000000
0-1 0-0.00000000
29
1 0 0 0.75000000
0 0-1-0.00000000
0 1 0 0.75000000
30
-1 0 0 0.25000000
0 0-1 0.25000000
0 1 0 0.00000000
31
1 0 0 0.75000000
0-1 0-0.00000000
0 0 1 0.75000000
32
-1 0 0 0.25000000
0-1 0 0.25000000
0 0 1 0.00000000
33
0 0 1 0.75000000
-1 0 0-0.00000000
0 1 0 0.75000000
34
0 1 0 0.00000000
0 0-1 0.25000000
-1 0 0 0.25000000
35
0 1 0 0.75000000
-1 0 0-0.00000000
0 0 1 0.75000000
36
0 0 1 0.00000000
0-1 0 0.25000000
-1 0 0 0.25000000
37
0 0-1 0.25000000
0 1 0 0.00000000
-1 0 0 0.25000000
38
0-1 0 0.25000000
0 0 1 0.00000000
-1 0 0 0.25000000
39
0 0-1-0.00000000
0 1 0 0.75000000
1 0 0 0.75000000
40
0-1 0-0.00000000
0 0 1 0.75000000
1 0 0 0.75000000
41
0 0-1 0.25000000
-1 0 0 0.25000000
0 1 0 0.00000000
42
0-1 0 0.25000000
-1 0 0 0.25000000
0 0 1 0.00000000
43
0 0-1-0.00000000
1 0 0 0.75000000
0 1 0 0.75000000
44
0-1 0-0.00000000
1 0 0 0.75000000
0 0 1 0.75000000
45
0 1 0 0.75000000
0 0-1-0.00000000
1 0 0 0.75000000
46
0 0 1 0.75000000
0-1 0-0.00000000
1 0 0 0.75000000
47
-1 0 0-0.00000000
0 0 1 0.75000000
0 1 0 0.75000000
48
More information about the Wien
mailing list