[Wien] Restarting HF with SO

[Gavin Abo]

Unfortunately, I think that error message can tell you "why" the 
calculation stopped, but it might not tell you the initial "cause" of 
it.  That is likely because the issue that caused it happened earlier in 
the calculation (perhaps lapw1?).  The vector file size is smaller than 
the vectorhf_old.  I'm not sure if they should be the same size or not.  
If so, perhaps you need to restart the calculation in the lapw1 step (-s 
lapw1) to regenerate the vector file instead of starting with the hf 
step (-s hf), which I believe comes later in the calculation from that 
of lapw1, or you might just have to start the calculation over from scratch.

In SRC_hf/calc_h_2.F, you should see:

line 1354:
!_COMPLEX call 
zheev('V','U',nbf,ham,nbf,enknew,workdiag,2*nbf-1,rworkdiag,info)

line 1365:
         if (info .ne. 0) then
           print *, 'info=', info
           stop 'error in calc_h_2: info not equal to 0'
         endif

 From the code above, you can see that there likely should be a little 
more error information available from the "print *, 'info=', info" 
statement that you did not report.  I believe this should have been 
printed to the standard output (terminal or std output file if you are 
using a queuing system).

Depending on the value of the info variable, the calculation seems to 
have stopped because it encountered an illegal value or there was a 
convergence problem [1]:

         INFO is INTEGER
           = 0:  successful exit
           < 0:  if INFO = -i, the i-th argument had an illegal value
           > 0:  if INFO = i, the algorithm failed to converge; i
                 off-diagonal elements of an intermediate tridiagonal
                 form did not converge to zero.

Perhaps, the software developers of the hf code have further insight 
than I currently do into what could resolve the problem.

[1] 
http://www.netlib.org/lapack/explore-html/df/d9a/group__complex16_h_eeigen_ga70c041fd19635ff621cfd5d804bd7a30.html#ga70c041fd19635ff621cfd5d804bd7a30

On 5/18/2017 5:52 AM, Luis Ogando wrote:
>    I do not know if it is relevant, but my calculation is complex (-c).
>    Thank you again,
>                     Luis
>
>
> 2017-05-18 8:29 GMT-03:00 Luis Ogando <lcodacal at gmail.com 
> <mailto:lcodacal at gmail.com>>:
>
>     Dear Wien2k community,
>
>        I am trying to calculate the dielectric function for wurtzite
>     GaP using -hf and -so as previously discussed (
>     http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14603.html
>     <http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14603.html>
>     ).
>        There was a shut down of the machine during the hf  execution
>     in the first step of the calculation (  run_lapw -hf ...  ). When
>     the machine came back, I removed the case.vectorhf
>     (case.vectorhf_old is still there) and case.energyhf.  Then, I
>     executed
>
>     run_lapw -hf -NI -s hf -ec 0.0001 -cc 0.0001 -i 200
>
>     trying to restart the calculation (non-parallel execution due to
>     the HF x SO issue discussed in the previous messages above).
>        The calculation restarted without a problem, but when the the
>     case.vectorhf reached 187MB (less than a half of the expected
>     size, see below) I got an error.
>
>     -rw-r--r-- 1 luisoda luisoda 187M Mai 18 03:51
>     GaPwurtHSE-DielSO-1.vector
>     -rw-r--r-- 1 luisoda luisoda 187M Mai 18 00:14
>     GaPwurtHSE-DielSO-1.vectorhf
>     -rw-r--r-- 1 luisoda luisoda 565M Abr 23 21:33
>     GaPwurtHSE-DielSO-1.vectorhf_old
>
>        The only related error message I found it was:
>
>     error in calc_h: info not equal to 0
>
>        I am probably making a mistake when restarting the calculation
>     and I would really appreciate any help with this issue.
>        Many thanks in advance.
>        All the best,
>                  Luis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20170518/999fbe91/attachment.html>