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.

Page: [1]

Thread Title (must) Move the thread to the top
Your Name (must)
E-Mail (must)
Password (used in modification of the submitted text)
Comment (must)

   Save Cookie