Top Page > Browsing

Bug in OpenMX Date: 2021/01/14 20:50 Name: Artem Pulkin   <gpulkin@gmail.com> 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  <gpulkin@gmail.com> 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. Regards, TO

Page: [1]