Dear users,
I am trying to run some SCF calculation using elk code. I started with the example given in
elk-5.2.14/examples/meta-GGA/GaAs-SCAN. For SCAN functional SCF cycle converges without any error.
Now I change the SCAN functional to TPSS and run again but this time I get the following error-
Info(elk): several copies of Elk may be running in this path
(this could be intentional, or result from a previous crash,
or arise from an incorrect MPI compilation)
Info(elk): current task : 0
Info(checkmt): reduced muffin-tin radius of species 1 (Ga) from 2.4000 to 2.2888
Info(checkmt): reduced muffin-tin radius of species 2 (As) from 2.4000 to 2.2888
Warning(rdirac): maximum iterations exceeded
Error(rdirac): zero wavefunction
I have attached INFO.OUT for both the functional. Can anyone please help me how to solve this problem?
with regards,
Bikash Patra,
NISER, Bhubaneswar, INDIA.
-
Hi,
The important part here is:
Warning(rdirac): maximum iterations exceeded
Error(rdirac): zero wavefunction
And, I've got the same error once and would like to know what it means.The other stuff is just info. The "several copies" info means that a file named RUNNING is present in your work folder, which means that the last job did not end correctly. No effect for the new job though.
Also, check your MT radii and geometry - those MTs are apparently too large, or the cell vectors are too short. All lengths must be in bohr, just in case.
The radii affect the quality of calculation, see keywords rgkmax and isgkmax.Best regards.
Andrew
Last edit: Andrew Shyichuk 2019-01-26-
-
Hi Bikash and Andrew,
Many meta-GGA functionals (including TPSS) don't work in Elk.
We think the fault is not with Elk or Libxc but rather with the functionals themselves. Many of the meta-GGA functionals return unreasonable potentials when the density gradients and tau are large (as they are near the nucleus). Elk is one of the few (only?) all-electron codes which treat meta-GGA variationally, so this may not have been noticed before.
In fact, the only functional that we've found to work reliably in Elk is SCAN.
Regards,
Kay.
-
Dear Kay,
Back in 4.3.6, the only mGGAs that worked were BJ, TB-mBJ and RPP09 (207-209 in libxc). I use RPP09 a lot, and I nave no cmplains about it.
If density gradient is indeed the issue, could spikes/discontinuities at MT boundary and/or at inner/outer part of MT be the source of the problem?
If, however, it is about the nucleus, can a core hole be used? Let's say, a small hole, like 0.1 bohr around the nucleus?
Best regards.
Andrii
-
The Becke-Johnson functionals produce only the potential and not the energy. They are fairly stable in Elk.
SCAN, TPSS, etc. are energy functionals which require functional derivatives. These derivatives appear to have come uncontrolled asymtotes for large gradients.
You could try limiting the gradients with a core hole, but I would much rather fix the functionals themselves. SCAN seems to have got this right and, in our experience, gives accurate results when used variationally.
Regards,
Kay.
Last edit: J. K. Dewhurst 2019-01-26
-
Indeed, fixing functionals would be the right thing to do.
I was looking at the problem in a more pragmatic way, with a simple working solution.
So, is there a core hole feature in elk?
-
There is no core hole feature -- you'll have to hack the code.
Cheers,
Kay.
-
Dear Kay,
I want to intall elk with libxc version 5.0.0. I tried with the same procedure as with libxc version 4.x but it falied. There are some recent new meta-GGA functionals in libxc recent version. I want to test whether those are working with elk. Could you please tell what changes needs to be done to install elk with libxc version 5.0.0?Regards,
Bikash.
-
Hi Bikash,
Libxc 5.0.0 was released a few days ago and we haven't had time to look at it.
I'll make the next Elk release compatible with it though -- probably in a week or two.
Regards,
Kay.
-
https://bugzilla.redhat.com/show_bug.cgi?id=1831479
Is the error below related to libx5 only or also to gfortran-10.0.1 used on the latest fedora (rawhide)?
... gfortran -fopenmp -fallow-argument-mismatch -I/usr/lib64/gfortran/modules -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c libxcifc.f90 f951: Warning: '-Werror=' argument '-Werror=format-security' is not valid for Fortran libxcifc.f90:100:23: 100 | type(xc_f90_pointer_t) p,info | 1 Error: Derived type 'xc_f90_pointer_t' at (1) is being used before it is defined libxcifc.f90:320:23: 320 | type(xc_f90_pointer_t) p,info | 1 Error: Derived type 'xc_f90_pointer_t' at (1) is being used before it is defined libxcifc.f90:388:23: 388 | type(xc_f90_pointer_t) p,info | 1 Error: Derived type 'xc_f90_pointer_t' at (1) is being used before it is defined libxcifc.f90:407:32: 407 | call xc_f90_func_init(p,info,id,XC_UNPOLARIZED) | 1 Error: Symbol 'info' at (1) has no IMPLICIT type libxcifc.f90:407:27: 407 | call xc_f90_func_init(p,info,id,XC_UNPOLARIZED) | 1 Error: Symbol 'p' at (1) has no IMPLICIT type libxcifc.f90:344:30: 344 | call xc_f90_func_init(p,info,id,nspin) | 1 Error: Symbol 'info' at (1) has no IMPLICIT type libxcifc.f90:344:25: 344 | call xc_f90_func_init(p,info,id,nspin) | 1 Error: Symbol 'p' at (1) has no IMPLICIT type libxcifc.f90:131:32: 131 | call xc_f90_func_init(p,info,id,nspin) | 1 Error: Symbol 'info' at (1) has no IMPLICIT type libxcifc.f90:131:27: 131 | call xc_f90_func_init(p,info,id,nspin) | 1 Error: Symbol 'p' at (1) has no IMPLICIT type libxcifc.f90:8:4: 8 | use xc_f90_lib_m | 1 ...... 411 | call xc_f90_hyb_exx_coef(p,hybridc) | 2 Error: 'xc_f90_hyb_exx_coef' at (1) has a type, which is not consistent with the CALL at (2)
Full build log at https://koji.fedoraproject.org/koji/taskinfo?taskID=44204494
-
Hi Marcin,
It looks like there have been a few changes between versions 4 and 5 of Libxc.
I'll have it fixed by the next release of Elk. In the meantime, use Libxc version 4.x if possible.
Regards,
Kay.
Please follow https://gitlab.com/libxc/libxc/-/issues/186 - there is another libxc release coming up with some fixes
Indeed, fixing functionals would be the right thing to do.
I was looking at the problem in a more pragmatic way, with a simple working solution.
So, is there a core hole feature in elk?
https://sourceforge.net/p/elk/discussion/897820/thread/cf6a12d792/
0 Comments