Re: Wrong Uele for periodic system with large basis ( No.1 ) 
 Date: 2017/06/05 05:20
 Name: Chris Latham
 Hello Daniil,
It looks like the basis set is overcomplete, and has resulted in an unphysical SCF solution. This is a purely numerical problem, and not the fault of OpenMX.
Use a smaller basis.
Best wishes,
Christopher.

Re: Wrong Uele for periodic system with large basis ( No.2 ) 
 Date: 2017/06/05 08:52
 Name: Daniil
 Hi Chris,
That is obvious assumption, but it looks like that it is not the case. I am now rerunning calculation with "scf.ProExpn.VNA off" and at the first scf step Uele is about 203, which is close to smaller basis result. So that, the problem seems to be in projector expanding, or at least in something related to it. (At the first scf step in the case of smaller basis, Uele was also about 203)
Best regards, Daniil

Re: Wrong Uele for periodic system with large basis ( No.3 ) 
 Date: 2017/06/05 18:31
 Name: Chris Latham
 Hello Daniil,
The basis is so enormous that you may still be in trouble. Have you tried increasing scf.energycutoff? However, I think you will be better off making a smaller, optimized basis in the long run. If this solves your problem, then please let us know, and mark the thread as [SOLVED].
Best wishes,
Christopher.

Re: Wrong Uele for periodic system with large basis ( No.4 ) 
 Date: 2017/06/05 21:13
 Name: Daniil
 Hello Chris,
My calculations are still running, but Uele is already 195.576557939641, so that it is very likely to converge to a value similar to smaller basis result. So, it is theoretically possible to use such basis sets in Openmx, however, with "scf.ProExpn.VNA off" only.
I checked manual once more and found this node: openmxsquare.org/openmx_man3.8/node175.html . So, it is a known problem. Unfortunately, increasing scf.energycutoff also significantly increases memory usage, and for example, value of 500 Ryd leads to out of memory error on my resources.
Best regards, Daniil

