<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Thanks, Prof. Marks. Your explanation
is better than mine. Yes, almost certainly the default -r4 is
used for -O2, but by luck it is not truncating the variable.<br>
<br>
By the way, do you think it is also by luck that the ifort
compiler produces an "x symmetry" executable that does not crash
with a memory access violation outside the lm array for certain
structures? If you check SRC_symmet<b>ry</b>/class.f on line 8,
the array is allocated as lm(2,49). However, the array is only
allocated as lm(2,48) in kurki.f on line 3. Since class.f and
kurki.f in SRC_symmet<b>so</b> both have lm(2,49), it suggests
lm(2,48) should be replaced by lm(2,49). This would affect at
least Wienk2k 11 and 12.<br>
<br>
How I caught the potential issue on my system:<br>
<br>
1. Add capitalized -C in SRC_symmetry<b>/</b>Makefile<br>
2. make<br>
3. cp symmetry ..<br>
4. Use in2o3.struct in the Wien2k folder example_struct_files<br>
5. x symmetry<br>
6. The first line in the error message:<br>
<br>
forrtl: severe (408): fort: (2): Subscript #2 of the array LM has
value 49 which is greater than the upper bound of 48<br>
<br>
When "-C" is not used, the executable runs without error and seems
to produce the correct output for in2o3. The error cannot be
caught with TiC. <br>
<br>
On 7/29/2012 2:54 PM, Laurence Marks wrote:<br>
</div>
<blockquote
cite="mid:CANkSMZBX7+KC+YCL=jObBg-Q2=rxcQUmh5aUiO6RV5vHr+oJSg@mail.gmail.com"
type="cite">
<pre wrap="">Almost certainly it is trickier than this. I expect that -O1 is
truncating relevant variables to real*4 which is leading to problems.
With -O2 the compiler may well be not bothering to truncate and, at
the end of the space allocated for the variable, by luck the correct
values are present. This is luck; the same type of bug can in other
cases lead to segmentation violations when code gets overwritten.
N.B., I think there are only two places where real*4 variables are
used, in parts of aim and for storage of the Hamiltonian in lapw1.
Everything else should be real*8.
On Sun, Jul 29, 2012 at 3:05 PM, Gavin Abo <a class="moz-txt-link-rfc2396E" href="mailto:gsabo@crimson.ua.edu"><gsabo@crimson.ua.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I didn't use -r8. However, you are right. The scf cycle works
correctly if I use "-O1 -r8".
So the higher optimizations -O2 and -O3 must be invoking the use of -r8,
whereas -O0 and -O1 should be using the default -r4.
On 7/29/2012 1:40 PM, Laurence Marks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I have not tested, but it looks like you are probably right. There may
be other cases where variables are not explicitly defined to be 8
bytes which are normally hidden by the use of "-r8". Did you use -r8?
On Sun, Jul 29, 2012 at 1:57 PM, Gavin Abo <a class="moz-txt-link-rfc2396E" href="mailto:gsabo@crimson.ua.edu"><gsabo@crimson.ua.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Dear Prof. Blaha,
Thanks, the scf cycle runs correctly using -O2 or -O3 with the new
files for the "fftpack" routines. However, the scf cycle of the TiC
example does not converge with -O1 (in the lapw0 makefile) with wrong
values in TiC.output0 such as the plane wave contribution. I don't
know whether the problem is reproducible on another system.
It seems to be due to "IMPLICIT REAL*8 (A-H,O-Z)" not being in the
PIMACH function at the end of the fortran file fftpack_helpers.f.
This line is in the function in the old file zfft3d.F.
Kind Regards,
Gavin
On Thu, Jul 26, 2012 at 1:42 AM, Peter Blaha
<a class="moz-txt-link-rfc2396E" href="mailto:pblaha@theochem.tuwien.ac.at"><pblaha@theochem.tuwien.ac.at></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Thank's for the report.
The problem concerns lapw0, when compiled in sequential mode WITHOUT
-DFFTW2 or -DFFTW3
in the Makefile (i.e. using the old "fftpack" routines instead of the new
and faster fftw library).
The fix suggested in the mail below does not work. Instead, you have to
replace the 3 attached
subroutines and recompile. (eramps.f, fft_modules.F fftpack_helpers.f)
A corrected version is on the web.
PB
Am 25.07.2012 23:21, schrieb Gavin Abo:
</pre>
<blockquote type="cite">
<pre wrap="">Dear Prof. Blaha,
When I run the TiC example with WIEN2k 12 "without" k-point or mpi
parallelization, the program stops in lapw2 with the error shown below.
Here lapw2 cannot read the TiC.energy
file, because it is missing data in it as lapw0 gives bad output such as a
Density Integral with the value NaN in TiC.output0.
The problem seems to be related to the new fft module.
If lines 536-538 and 612-614 in SRC_lapw0/fft_modules.F:
N2 = N+N
DO 117 I=1,N2
C(I) = CH(I)
are both changed to:
DO 117 I=1,N
C(I) = CH(I)
Then, the error goes way. On my system, N was the number 64. The array C
had a size of 64, such that the loop is indexing outside the array (N2 =
128).
In Wien2k 11, TiC.output0 had:
PLANE WAVE CONTRIBUTION -0.235589
:DEN : DENSITY INTEGRAL = -754.35311720 (Ry)
In Wien2k 12 with both changes made in fft_modules.F, TiC.output0 had:
PLANE WAVE CONTRIBUTION -0.049778
:DEN : DENSITY INTEGRAL = -753.97972930 (Ry)
The density integral value is about the same, but the plane wave
contribution value may be significantly different. So I'm not completely
sure if my change is correct.
Therefore, please let me know if a different change is needed.
Thanks,
Gavin
forrtl: severe (59): list-directed I/O syntax error, unit 30, file
/home/gavin/wien/wiendata/TiC/TiC.energy
Image PC Routine Line Source
lapw2 000000000053676A Unknown Unknown Unknown
lapw2 0000000000535266 Unknown Unknown Unknown
lapw2 00000000004DFA30 Unknown Unknown Unknown
lapw2 000000000049BDEF Unknown Unknown Unknown
lapw2 000000000049B2F7 Unknown Unknown Unknown
lapw2 00000000004C10B3 Unknown Unknown Unknown
lapw2 0000000000437F93 fermi_tetra_ 516 fermi_tmp_.F
lapw2 0000000000437423 fermi_ 111 fermi_tmp_.F
lapw2 00000000004721BA MAIN__ 278 lapw2_tmp_.F
lapw2 0000000000403C9C Unknown Unknown Unknown
libc.so.6 00002B3BE2AF5C8D Unknown Unknown Unknown
lapw2 0000000000403B99 Unknown Unknown Unknown
</pre>
</blockquote>
<pre wrap="">--
P.Blaha
--------------------------------------------------------------------------
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
Email: <a class="moz-txt-link-abbreviated" href="mailto:blaha@theochem.tuwien.ac.at">blaha@theochem.tuwien.ac.at</a> WWW:
<a class="moz-txt-link-freetext" href="http://info.tuwien.ac.at/theochem/">http://info.tuwien.ac.at/theochem/</a>
--------------------------------------------------------------------------
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Wien mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Wien@zeus.theochem.tuwien.ac.at">Wien@zeus.theochem.tuwien.ac.at</a>
<a class="moz-txt-link-freetext" href="http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien">http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Wien mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Wien@zeus.theochem.tuwien.ac.at">Wien@zeus.theochem.tuwien.ac.at</a>
<a class="moz-txt-link-freetext" href="http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien">http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>