GitLab

Note: This seems to have introduced some bugs. ...to be corrected soon.

The continuous restartability still does not seem to work correctly.

This implies the reduction of required metric calls in the broyden code path
from 4 to 2. This is now equivalent to the number of metric calls in the
old broyden code path.

This is not yet fully functional and not yet activated in the code. To activate it
the broyden call in "mix" has to be replaced by a broyden2 call.

...this surely is not yet the final version.

..also in this commit: slight cleanup in mix/metric.f90

Note: Also in this commit:

1. Changed test values in NiO_ldauXML test since now the broyden files get deleted
   when a new density matrix is generated
2. The NiO_ldau test should not work any more since linear mixing for the density
   matrix is removed for the old inp file. (It is not specified in the n_mmp_mat
   file any more)

Up to now this is only a partial solution. There is still reading
of the n_mmp_mat file in the SCF loop to read in the optional mixing
parameters.

This is not yet tested.

This is to make it usable for situations where ufft is not
the step function. Christian has such situations.

Also corrected the documentation in convol.

removed: weight, natd, nkpts,nkptd

configure.sh script is doing part of the job now
more details should be found in README (later :-) )

changed phas(n) in spgrot.f to cc. Use cc of pgfft in pwden.F90,
partially in fft(3,2)d(xc).f90, and of phas in cdnovlp.F90.
Introduce complex phase & derived variables in q_int_sl.f90, hsint.F90,
vacfun.f90, potdis.f90. Initializations in strgn.f90, real arguments
for dot_product() in pwint(_sl).f90 & phasy1.f90. Stop message in
rw_symfile.f changed to 'complex phases not fully tested'.

In broyden.F90 sometimes the error floating invalid occured when extensive
runtime checks were enabled. The error occurs in the line were the arrays
sm and sm1 are subtracted from each other.

The conjectured cause for this is that only a part of the arrays is really
used. Their size is larger. The part that is not used is never initialized.
So it may occur that subtracting the arrays from each other results in
an invalid operation in the part of the array that is not used.

We could not directly verify this conjecture. But reducing the subtraction
to the used part seems to cure the problem. We did that and additionally
initialized the local arrays to 0.0.

Based on v0.26 hybrid branch