[Wien] Error in nlvdw
Gavin Abo
gsabo at crimson.ua.edu
Mon Feb 24 03:34:04 CET 2020
I did some more testing of the nlvdw package compiled with gfortran with
.outputnlvdw having unit 6. A nlvdw calculation runs fine. It does
appear to just be due to a deficiency of resources for my system.
Further details given below should you be interested in them.
In gcc-7.4.0.tar.gz at [1], it can be seen in gcc/fortran/libgfortran.h
that unit 6 and 5 are preconnected as standard output and standard
input, respectively, from:
/* Default unit number for preconnected standard input and output. */
#define GFC_STDIN_UNIT_NUMBER 5
#define GFC_STDOUT_UNIT_NUMBER 6
#define GFC_STDERR_UNIT_NUMBER 0
However, as stated at [2]:
/Like any other preconnected unit it may have its connection changed in
an open statement./
Indeed, the preconnection of unit 6 as standard output is overridden to
write to the .outputnlvdw file instead by the open statement in WIEN2k's
SRC_nlvdw/vdw.F (on line 87 when iunit=6):
open (iunit,file=fname,status=status,form=form)
When I tried running Dr. Chakrabarti's alloy_VOPT.struct at [3] with
"run_lapw -nlvdw", the .dayfile gave me a "Killed" error and
.outputnlvdw was empty.
When I ran it, I found it strange that .outputnlvdw was empty. It turned
out that gfortran buffers file output in memory by default such that the
output was never written to the file when the program was killed. I
have found that the environmental variable GFORTRAN_UNBUFFERED_ALL can
be set to 1 [4]. Using GFORTRAN_UNBUFFERED_ALL can slow down the small
sequential reads and writes [5] but is obviously better for debugging
and also got me passed what I previously reported that might be a
gfortran bug with buffered file output when using unit 6. As using a
'print *,iunit' statement to try to debug the above open statement in
vdw.F printed to the .dayfile that files up to unit 5 were opened but
never showed unit 6 and the later files from nlvdw.def opening.
The calculation I ran made it to the same spot as Dr. Chakrabarti and
expect the Ubuntu killed it due to insufficient RAM as Prof. Tran
pointed out at [6]. The small resource Al calculation ran without
errors though as shown below.
*alloy_VOPT Calculation*
username at computername:~/wiendata/alloy_VOPT$ ls
alloy_VOPT.struct
username at computername:~/wiendata/alloy_VOPT$ init_lapw -b
...
username at computername:~/wiendata/alloy_VOPT$ gedit alloy_VOPT.in0
username at computername:~/wiendata/alloy_VOPT$ cat alloy_VOPT.in0
TOT XC_GGA_X_B86_R EC_LDA VC_LDA (XC_LDA,XC_PBESOL,XC_WC,XC_MBJ,XC_SCAN)
NR2V IFFT (R2V)
144 144 144 2.00 1 NCON 9 # min IFFT-parameters, enhancement
factor, iprint, NCON n
username at computername:~/wiendata/alloy_VOPT$ cp
$WIENROOT/SRC_templates/case.innlvdw alloy_VOPT.innlvdw
username at computername:~/wiendata/alloy_VOPT$ gedit alloy_VOPT.innlvdw
username at computername:~/wiendata/alloy_VOPT$ cat alloy_VOPT.innlvdw
1 kernel type
-1.887 parameters of the kernel
25 plane-wave expansion cutoff GMAX
0.3 density cutoff rhoc
T calculation of the potential (T or F)
10 plane-wave expansion cutoff GMAXpot for the potential
username at computername:~/wiendata/alloy_VOPT$ export
GFORTRAN_UNBUFFERED_ALL=1
username at computername:~/wiendata/alloy_VOPT$ run_lapw -nlvdw
hup: Command not found.
grep: *scf1*: No such file or directory
grep: lapw2*.error: No such file or directory
> stop error
username at computername:~/wiendata/alloy_VOPT$ cat alloy_VOPT.dayfile
Calculating alloy_VOPT in /home/username/wiendata/alloy_VOPT
on computername with PID 26433
using WIEN2k_19.1 (Release 25/6/2019) in /home/username/WIEN2k
start (Sun Feb 23 17:47:33 MST 2020) with nlvdw (40/99 to go)
cycle 1 (Sun Feb 23 17:47:33 MST 2020) (40/99 to go)
> nlvdw (17:47:33) Killed
710.0u 58.6s 1:18:02.53 16.4% 0+0k 7490168+40io 262257pf+0w
error: command /home/username/WIEN2k/nlvdw nlvdw.def failed
> stop error
username at computername:~/wiendata/alloy_VOPT$ cat alloy_VOPT.outputnlvdw
kernel type = 1 (M. Dion et al., PRL 92, 246401 (2004))
parameter Z_ab of kernel = -1.88700000
gmax = 25.0
density cutoff rhoc = 0.300E+00
the NL-vdW potential is calculated with gmax_pot = 10.0
n_max, m_max, p_max = 101 101 101
ifft1, ifft2, ifft3 (for proc myid 0) = 203 203 203
ifft1*ifft2*ifft3 (for proc myid 0) = 8365427
Number of G-vectors (for proc myid 0) = 3099627
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% %
% You are using vdW-DF, which was implemented by the Thonhauser group. %
% Please cite the following two papers that made this development %
% possible and the two reviews that describe the various versions: %
% %
% T. Thonhauser et al., PRL 115, 136402 (2015). %
% T. Thonhauser et al., PRB 76, 125112 (2007). %
% K. Berland et al., Rep. Prog. Phys. 78, 066501 (2015). %
% D.C. Langreth et al., J. Phys.: Condens. Matter 21, 084203 (2009). %
% %
% %
% If you are calculating the stress with vdW-DF, please also cite: %
% %
% R. Sabatini et al., J. Phys.: Condens. Matter 24, 424209 (2012). %
% %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
parameters of the kernel table:
Nq = 30, lambda = 0.111292E+01, q(1) = 0.100000E-04, q_cut = 0.100000E+02
Nr_points = 2000, r_max = 100.0
q_mesh =
0.00001000 0.05312929 0.11224701 0.17804050
0.25126365 0.33275542 0.42344952 0.52438515
0.63671875 0.76173753 0.90087384 1.05572188
1.22805595 1.41985071 1.63330352 1.87086022
2.13524270 2.42948008 2.75694394 3.12138629
3.52698255 3.97838044 4.48075151 5.03985262
5.66208887 6.35459089 7.12529230 7.98302412
8.93761444 10.00000000
*Al Calculation*
username at computername:~/wiendata/Al$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic
username at computername:~/wiendata/Al$ cat $WIENROOT/WIEN2k_VERSION
WIEN2k_19.1 (Release 25/6/2019)
username at computername:~/wiendata/Al$ dpkg -l gfortran
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
ii gfortran 4:7.4.0-1ubu amd64 GNU Fortran 95 compiler
username at computername:~/wiendata/Al$ ls
Al.struct
username at computername:~/wiendata/Al$ init_lapw -b
...
username at computername:~/wiendata/Al$ cp
$WIENROOT/SRC_templates/case.innlvdw Al.innlvdw
For rev-vdW-DF2:
username at computername:~/wiendata/Al$ cat Al.innldvdw
1 kernel type
-1.887 parameters of the kernel
25 plane-wave expansion cutoff GMAX
0.3 density cutoff rhoc
T calculation of the potential (T or F)
10 plane-wave expansion cutoff GMAXpot for the potential
username at computername:~/wiendata/Al$ cat Al.in0
TOT XC_GGA_X_B86_R EC_LDA VC_LDA (XC_LDA,XC_PBESOL,XC_WC,XC_MBJ,XC_SCAN)
NR2V IFFT (R2V)
30 30 30 2.00 1 NCON 9 # min IFFT-parameters, enhancement
factor, iprint, NCON n
username at computername:~/wiendata/Al$ run_lapw -nlvdw
...
in cycle 6 ETEST: .0003618600000000 CTEST: .0358926
hup: Command not found.
STOP NLVDW END
STOP LAPW0 END
STOP LAPW1 END
STOP LAPW2 END
STOP CORE END
STOP MIXER END
ec cc and fc_conv 1 1 1
> stop
[1] http://mirrors.ocf.berkeley.edu/gnu/gcc/gcc-7.4.0/
[2]
https://stackoverflow.com/questions/44867775/fortran-code-wont-write-to-file
[3]
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg19663.html
[4]
https://stackoverflow.com/questions/1533717/how-do-i-flush-output-to-file-after-each-write-with-a-gfortran-fortran-90-progra
[5]
https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gfortran/GFORTRAN_005fUNBUFFERED_005fALL.html
[6]
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg19667.html
On 2/17/2020 3:16 AM, Peter Blaha wrote:
> But in nlvdw we do NOT write to the screen (except in case of some
> errors).
>
> In any case, please change nlvdw.def unit 6 to 66 and run nlvdw
> nlved.def to verify if this is the source of the problem.
> It should print all output on the screen then.
>
>
> On 2/16/20 6:39 PM, Gavin Abo wrote:
>> Perhaps it's just my system but the WIEN2k 19.1 nlvdw, which has been
>> compiled with gfortran (gcc version 7.4.0 under Ubuntu 18.04.4 LTS),
>> is behaving strangely. It seems to get hung up trying to open
>> $file.outputnlvdw in SCR_nlvdw/vdw.F. In x_lapw, I see
>> $file.outputnlvdw defined as unit 6.
>>
>>
>> It might be that use of unit 6 in the nlvdw package is problematic
>> when compiled with gfortran similar to what we saw for SRC_symmetry:
>>
>>
>> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16674.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20200223/6b385876/attachment-0001.html>
-------------- next part --------------
Al
F LATTICE,NONEQUIV.ATOMS: 1 225_Fm-3m
MODE OF CALC=RELA unit=ang
7.660953 7.660953 7.660953 90.000000 90.000000 90.000000
ATOM 1: X=0.00000000 Y=0.00000000 Z=0.00000000
MULT= 1 ISPLIT= 2
Al NPT= 781 R0=0.00010000 RMT= 2.5000 Z: 13.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-1 0 0.00000000
0 0 1 0.00000000
2
-1 0 0 0.00000000
0 1 0 0.00000000
0 0-1 0.00000000
3
1 0 0 0.00000000
0-1 0 0.00000000
0 0-1 0.00000000
4
0 0 1 0.00000000
1 0 0 0.00000000
0 1 0 0.00000000
5
0 0 1 0.00000000
-1 0 0 0.00000000
0-1 0 0.00000000
6
0 0-1 0.00000000
-1 0 0 0.00000000
0 1 0 0.00000000
7
0 0-1 0.00000000
1 0 0 0.00000000
0-1 0 0.00000000
8
0 1 0 0.00000000
0 0 1 0.00000000
1 0 0 0.00000000
9
0-1 0 0.00000000
0 0 1 0.00000000
-1 0 0 0.00000000
10
0 1 0 0.00000000
0 0-1 0.00000000
-1 0 0 0.00000000
11
0-1 0 0.00000000
0 0-1 0.00000000
1 0 0 0.00000000
12
0 1 0 0.00000000
1 0 0 0.00000000
0 0-1 0.00000000
13
0-1 0 0.00000000
-1 0 0 0.00000000
0 0-1 0.00000000
14
0 1 0 0.00000000
-1 0 0 0.00000000
0 0 1 0.00000000
15
0-1 0 0.00000000
1 0 0 0.00000000
0 0 1 0.00000000
16
1 0 0 0.00000000
0 0 1 0.00000000
0-1 0 0.00000000
17
-1 0 0 0.00000000
0 0 1 0.00000000
0 1 0 0.00000000
18
-1 0 0 0.00000000
0 0-1 0.00000000
0-1 0 0.00000000
19
1 0 0 0.00000000
0 0-1 0.00000000
0 1 0 0.00000000
20
0 0 1 0.00000000
0 1 0 0.00000000
-1 0 0 0.00000000
21
0 0 1 0.00000000
0-1 0 0.00000000
1 0 0 0.00000000
22
0 0-1 0.00000000
0 1 0 0.00000000
1 0 0 0.00000000
23
0 0-1 0.00000000
0-1 0 0.00000000
-1 0 0 0.00000000
24
-1 0 0 0.00000000
0-1 0 0.00000000
0 0-1 0.00000000
25
1 0 0 0.00000000
0 1 0 0.00000000
0 0-1 0.00000000
26
1 0 0 0.00000000
0-1 0 0.00000000
0 0 1 0.00000000
27
-1 0 0 0.00000000
0 1 0 0.00000000
0 0 1 0.00000000
28
0 0-1 0.00000000
-1 0 0 0.00000000
0-1 0 0.00000000
29
0 0-1 0.00000000
1 0 0 0.00000000
0 1 0 0.00000000
30
0 0 1 0.00000000
1 0 0 0.00000000
0-1 0 0.00000000
31
0 0 1 0.00000000
-1 0 0 0.00000000
0 1 0 0.00000000
32
0-1 0 0.00000000
0 0-1 0.00000000
-1 0 0 0.00000000
33
0 1 0 0.00000000
0 0-1 0.00000000
1 0 0 0.00000000
34
0-1 0 0.00000000
0 0 1 0.00000000
1 0 0 0.00000000
35
0 1 0 0.00000000
0 0 1 0.00000000
-1 0 0 0.00000000
36
0-1 0 0.00000000
-1 0 0 0.00000000
0 0 1 0.00000000
37
0 1 0 0.00000000
1 0 0 0.00000000
0 0 1 0.00000000
38
0-1 0 0.00000000
1 0 0 0.00000000
0 0-1 0.00000000
39
0 1 0 0.00000000
-1 0 0 0.00000000
0 0-1 0.00000000
40
-1 0 0 0.00000000
0 0-1 0.00000000
0 1 0 0.00000000
41
1 0 0 0.00000000
0 0-1 0.00000000
0-1 0 0.00000000
42
1 0 0 0.00000000
0 0 1 0.00000000
0 1 0 0.00000000
43
-1 0 0 0.00000000
0 0 1 0.00000000
0-1 0 0.00000000
44
0 0-1 0.00000000
0-1 0 0.00000000
1 0 0 0.00000000
45
0 0-1 0.00000000
0 1 0 0.00000000
-1 0 0 0.00000000
46
0 0 1 0.00000000
0-1 0 0.00000000
-1 0 0 0.00000000
47
0 0 1 0.00000000
0 1 0 0.00000000
1 0 0 0.00000000
48
More information about the Wien
mailing list