This thread is locked.Only browsing is available.
Top Page > Browsing
Bug in OpenMX
Date: 2021/01/14 20:50
Name: Artem Pulkin   <>

Disclaimer: I supposed to have the latest patch but I did not check it right now.

First of all I would like to understand what these lines in Band_DFT_Col.c and Band_DFT_NonCol.c mean:

if (lumos<60.0) lumos = 400.0;

According to the context, `lumos` is a variable responsible for the number of computed states in occupied space. But why 60 and 400?

The bug

File: Band_DFT_NonCol.c:250

MaxN = (TZ-system_charge)/2 + (int)lumos;

should be

MaxN = (TZ-system_charge) + (int)lumos;

for obvious reasons.
What happens currently is whenever `lumos < TZ / 2` (system_charge = 0) the number of computed bands becomes less than the number electrons.
For small systems this is (kind of) impossible because lumos is hard-coded to be 400 and TZ is typically much smaller.
For large systems lumos is defined to be 20% of the basis size.
I.e. the bug appears in non-collinear calculations of large systems with small/minimal basis sizes.
The calculation typically does not converge which is good because it would be really frustrating to know that non-collinear calculations with this bug are published.
Page: [1]

Re: Bug in OpenMX ( No.1 )
Date: 2021/01/14 21:23
Name: Artem Pulkin  <>

To add to the above, the bug is reproduced only with k-point grid. Also I believe that lumos defined as a percentage of the basis does not make any sense. It should be a fraction of the occupied space instead.
Re: Bug in OpenMX ( No.2 )
Date: 2021/08/02 23:37
Name: T. Ozaki

Dear Dr. Pulkin,

Thank you very much for your critical report.
This is a bug indeed.
I am going to fix the bug in an upcoming patch.



Page: [1]