<div dir="ltr">As mentioned in the other responses, so long as an array is large enough there is no problem with having it dimensioned smaller than this in fortran (with some caveats about passing values via subroutines).<div>
<br></div><div>The even case does for certain have a bug, and the relevant lines in dergl_spline should be</div><div><br></div><div><div> if(.not.even)then</div><div> do J=1,n</div><div> rw(-J)=-r(j)</div>
<div> w1(-J)=-f(J)</div><div> enddo</div><div> rw(0)=0.D0</div><div> w1(0)=0.D0</div><div> else</div><div> do J=1,n !-1 Bug here found by Kevin Jorissen</div>
<div> rw(-J+1)=-r(j)</div><div> w1(-J+1)= f(J)</div><div> enddo</div><div> endif</div></div><div><br></div><div>I think Peter may have already found this one and it is cured in the next release, but I am not sure.</div>
<div><br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 15, 2014 at 5:20 PM, Kevin Jorissen <span dir="ltr"><<a href="mailto:kevinjorissenpdx@gmail.com" target="_blank">kevinjorissenpdx@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div dir="ltr">Dear WIEN2k community,
<div><br>
</div>
<div><br>
</div>
<div>I have identified some issues in v.13 of the SRC_lapw0 code that prevented me from compiling a working Mac OS X version. I am also submitting a solution. The details are below my signature. After the code edits, I can compile and run lapw0 correctly
using the recommended compilation settings (no additional flags like -O0 or -fp-model strict). </div>
<div><br>
</div>
<div>The issue is somewhat sloppy code, legal in Fortran but vulnerable to compiler trip-ups, in the "drho" section of lapw0. It is quite possible that these issues do not occur on Linux, as memory is managed differently on the different OS's (e.g. which variables
go on stack or heap depending on their allocation). Nevertheless it seems useful to report. They occur for me with both gfortran and ifort, indicating it's not just Intel goofiness. I would be grateful for feedback from the developers or the community.
I'm happy to send source files - didn't include them now as I'm not sure the mailing list accepts attachments.</div>
<div><br>
</div>
<div>Finally, are total energies expected to be identical between wien2k_12 and wien2k_13? Or are small differences ~10^-4 or ~10^-5 normal?</div>
<div><br>
</div>
<div><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>Kevin Jorissen</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Details:</div>
<div>OS X 10.9.4</div>
<div>ifort 14.0.1 or ifort 14.0.2 or gfortran 4.9.0</div>
<div><br>
</div>
<div>Test:</div>
<div>* Standard "run_lapw" for HOPG graphite.</div>
<div>* The test is passed if the calculation: a/ does not crash ; b/ converges to approximately the same total energy (grep :ENE case.scf) as a wien2k-12 calculation (compiled with the same compiler as wien2k-13 and with "safe" options (no optimization)).
Initialization is done with that same wien2k-12 version, i.e. I test only the "SCF" programs.</div>
<div><br>
</div>
<div>Outcome:</div>
<div>* The test did not pass. The wien2k-13 calculation fails almost always: A seclr4 error in lapw1 following NaN in the case.scf0 and case.output0, so the problem is in lapw0. Case.scf0 points to the xcpot1 section. <a href="http://wien2k.at" target="_blank">wien2k.at</a>
reports updates to the "drho" in v.13. The crash occurs in varying SCF iteration for each run, indicating an "instability", i.e. numerical noise or memory issues.</div>
<div>* Trying different configurations didn't help. E.g. "safe" compilation options (-O0 -fp-model strict ...) ; e.g. swapping ifort for gfortran ; trying different fftw libraries ...</div>
<div><br>
</div>
<div>Solution (after tedious debugging ...):</div>
<div>Several small code changes in drho.f and dergl.f to correct array size issues.</div>
<div><br>
</div>
<div>DRHO.F</div>
<div>* The array "r" passed to dergl is size "nrad" (allocated elsewhere) while dergl expects an array of size "n=jri(jatom)". E.g. 881 vs. 781 for my test.</div>
<div>Solution (it could be done just by restricting call(...r(1:n)...) also):</div>
<div>
<p style="margin:0px;font-size:11px;font-family:Menlo"> <span style="color:rgb(187,44,162)">real</span>*<span style="color:rgb(39,42,216)">8</span> :: rlocal(n)</p>
</div>
<div><br>
</div>
<div>
<p style="margin:0px;font-size:11px;font-family:Menlo"> rlocal(:)=<span style="color:rgb(39,42,216)">0.</span>d<span style="color:rgb(39,42,216)">0</span></p>
<p style="margin:0px;font-size:11px;font-family:Menlo"> <span style="color:rgb(187,44,162)">
do</span> i=<span style="color:rgb(39,42,216)">1</span>,min(size(r),n)</p>
<p style="margin:0px;font-size:11px;font-family:Menlo"> rlocal(i) = r(i)</p>
<p style="margin:0px;font-size:11px;font-family:Menlo"> <span style="color:rgb(187,44,162)">
enddo</span></p>
<p style="margin:0px;font-size:11px;font-family:Menlo;color:rgb(0,132,0)">! call dergl(n,r,c,g,even,g0)</p>
<p style="margin:0px;font-size:11px;font-family:Menlo;color:rgb(0,132,0)">! call dergl(n,r,g,g2,.not.even,g0)</p>
<p style="margin:0px;font-size:11px;font-family:Menlo"> <span style="color:rgb(187,44,162)">
call</span> dergl(n,rlocal,c,g,even,g<span style="color:rgb(39,42,216)">0</span>)</p>
<p style="margin:0px;font-size:11px;font-family:Menlo"></p>
<p style="margin:0px;font-size:11px;font-family:Menlo"> <span style="color:rgb(187,44,162)">
call</span> dergl(n,rlocal,g,g<span style="color:rgb(39,42,216)">2</span>,<span style="color:rgb(187,44,162)">.not.</span>even,g<span style="color:rgb(39,42,216)">0</span>)</p>
</div>
<div><br>
</div>
<div>DERGL.F</div>
<div>* In calls to Fornberg, the array "A(0:Ninp)" is made with a larger array "RW(I)". Solution: replace with appropriate subarray of size Ninp+1:</div>
<div>
<p style="margin:0px;font-size:11px;font-family:Menlo;color:rgb(0,132,0)">! call Fornberg(Ninp,Minp,RW(J),RW(J-N1),D)</p>
<p style="margin:0px;font-size:11px;font-family:Menlo"> <span style="color:rgb(187,44,162)">
call</span> Fornberg(Ninp,Minp,RW(J),RW(J-N<span style="color:rgb(39,42,216)">1</span>:J-N<span style="color:rgb(39,42,216)">1</span>+Ninp),D)</p>
</div>
<div><br>
</div>
<div>
<p style="margin:0px;font-size:11px;font-family:Menlo;color:rgb(0,132,0)">! call Fornberg(Ninp,Minp,R(J),R(JL),D)</p>
<p style="margin:0px;font-size:11px;font-family:Menlo"> <span style="color:rgb(187,44,162)">
call</span> Fornberg(Ninp,Minp,R(J),R(JL:JL+Ninp),D)</p>
<p style="margin:0px;font-size:11px;font-family:Menlo"><br>
</p>
</div>
<div>
<p style="margin:0px;font-size:11px;font-family:Menlo;color:rgb(0,132,0)">! call Fornberg(Ninp,Minp,0.0D0,RW(-N1),D)</p>
<p style="margin:0px;font-size:11px;font-family:Menlo"> <span style="color:rgb(187,44,162)">
call</span> Fornberg(Ninp,Minp,<span style="color:rgb(39,42,216)">0.0</span>D<span style="color:rgb(39,42,216)">0</span>,RW(-N<span style="color:rgb(39,42,216)">1</span>:-N<span style="color:rgb(39,42,216)">1</span>+Ninp),D)</p>
<p style="margin:0px;font-size:11px;font-family:Menlo"><br>
</p>
</div>
<div>* In subroutine dergl_spline, rw is not initialized correctly for the "even" case: the lower point rw(-n+1) is uninitialized and could be anything. Solution:</div>
<div>
<p style="margin:0px;font-size:11px;font-family:Menlo"> <span style="color:rgb(187,44,162)">else</span></p>
<p style="margin:0px;font-size:11px;font-family:Menlo"> <span style="color:rgb(187,44,162)">
do</span> J=<span style="color:rgb(39,42,216)">1</span>,n<span style="color:rgb(39,42,216)">-1</span></p>
<p style="margin:0px;font-size:11px;font-family:Menlo"> rw(-J<span style="color:rgb(39,42,216)">+1</span>)=-r(j)</p>
<p style="margin:0px;font-size:11px;font-family:Menlo"> w<span style="color:rgb(39,42,216)">1</span>(-J<span style="color:rgb(39,42,216)">+1</span>)= f(J)</p>
<p style="margin:0px;font-size:11px;font-family:Menlo"> <span style="color:rgb(187,44,162)">
enddo</span></p>
<p style="margin:0px;font-size:11px;font-family:Menlo"> rw(-n<span style="color:rgb(39,42,216)">+1</span>)=-r(n) ! initialize this field!</p>
<p style="margin:0px;font-size:11px;font-family:Menlo;color:rgb(0,132,0)"><span style="color:rgb(0,0,0)"> w</span><span style="color:rgb(39,42,216)">1</span><span style="color:rgb(0,0,0)">(-n</span><span style="color:rgb(39,42,216)">+1</span><span style="color:rgb(0,0,0)">)=f(n)
</span>! Technically this is redundant (see w1=0 above).</p>
<p style="margin:0px;font-size:11px;font-family:Menlo"> <span style="color:rgb(187,44,162)">
endif</span></p>
</div>
<div><span style="color:rgb(187,44,162)"><br>
</span></div>
<div><br>
</div>
<div>PS xcpot1.f has some unrelated issue with sigmamaxup and irsigmaup, which gets used without being initialized or something like that. I don't remember the details now, and it doesn't seem to hinder the program, but it popped up during a runtime check
at some point - I believe it was triggered by a WRITE statement containing r(irsigmaup) when irsigmaup can be uninitialized.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>TEST SCRIPT:</div>
<div><br>
</div>
<div>
<p style="margin:0px;font-size:11px;font-family:Menlo">~/science/graphite13-opt-test% more ../MyWienTest </p>
<p style="margin:0px;font-size:11px;font-family:Menlo">#!/bin/tcsh -f</p>
<p style="margin:0px;font-size:11px;font-family:Menlo;min-height:13px"><br>
</p>
<p style="margin:0px;font-size:11px;font-family:Menlo">echo Running test in `pwd`</p>
<p style="margin:0px;font-size:11px;font-family:Menlo">echo WIENROOT is $WIENROOT</p>
<p style="margin:0px;font-size:11px;font-family:Menlo">rm -f *scf* *clm* *broy* *tmp* *vec* *def *error :log</p>
<p style="margin:0px;font-size:11px;font-family:Menlo">x dstart -d</p>
<p style="margin:0px;font-size:11px;font-family:Menlo">~/science/wien2k-12-noopt/dstart dstart.def</p>
<p style="margin:0px;font-size:11px;font-family:Menlo">run -ec 0.000001</p>
<p style="margin:0px;font-size:11px;font-family:Menlo;min-height:13px"><br>
</p>
<p style="margin:0px;font-size:11px;font-family:Menlo">exit 0</p>
<p style="margin:0px;font-size:11px;font-family:Menlo;min-height:13px"><br>
</p>
</div>
<div><br>
</div>
</div>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Professor Laurence Marks<br>Department of Materials Science and Engineering<br>Northwestern University<br><a href="http://www.numis.northwestern.edu" target="_blank">www.numis.northwestern.edu</a><div>
Corrosion in 4D: <a href="http://www.numis.northwestern.edu/MURI" target="_blank">www.numis.northwestern.edu/MURI</a><br>Co-Editor, Acta Cryst A<br>"Research is to see what everybody else has seen, and to think what nobody else has thought"<br>
Albert Szent-Gyorgi</div></div>
</div>