Serious bug found in constrmag.F for vasp.6
Posted: Mon Jul 06, 2020 1:32 pm
Using the NiO example from the Wiki I just wanted to test and check
different settings of KPAR, NCORE (some years ago one of our students
mentioned there could be a bug ...) -> a complete desaster, did not
work at all, results were different from vasp.5.4.4, found partly "random
results" for different machines and settings and startup times ... .
Problem identified and necessary fix: There is an accidental explicit
(re-)declaration of variable NTYP (already declared in the head of the
module at line 9!) in subroutine CONSTRAINED_M_INIT (at line 165). The
tragic consequence is: This (despite the previous declaration allowed)
second declaration overrides the previous definition locally for this
specific subroutine, making it a new local variable there which is in
particular uninitialized there (undefined value!!!). Depending on
platform, date, time, whatever it could at best contain a zero (what
would result in a non-execution of the loop DO NT=1,NTYP) but sometimes
it could have any value (also >0, >whatever) resulting in unpredictable
"random results" (in some cases even segmentation faults ...). The very
simple fix is just to remove NTYP from the declaration list in line 165,
i.e., replace the old (incorrect) statement
INTEGER NTYP, NIS, NT, N1LOW, N2LOW, N3LOW, N1HI, N2HI, N3H
by the new correct statement
INTEGER NIS, NT, N1LOW, N2LOW, N3LOW, N1HI, N2HI, N3HI
and everything will work fine again (for any KPAR and NCORE ...).
This bug was not present in vasp.5.x because it stems from a removal of
all implicit type declarations (in favor of "IMPLICIT NONE" and explicit type
declarations) when moving from vasp.5 to vasp.6 (one declaration too much).
I also stumbled over some other (less serious) bug (that should also be
fixed) in routine XML_WRITE_CONSTRAINED_M: There, on line 148, I found
some XML output call for "AM_CONSTR"
CALL XML_INCAR_V('M_CONSTR','F',IDUM,AM_CONSTR,CDUM,...
but I'm quite convinced that you wanted to write out "M_CONSTR" instead
(or not ??), so you should replace that then by (kill the "A" ... ;-))
CALL XML_INCAR_V('M_CONSTR','F',IDUM,M_CONSTR,CDUM,...
(and again the declaration of AM_CONSTR in line 140 can/must also
be removed, i.e. it should only read "REAL(q) RDUM" then ... [?]).
different settings of KPAR, NCORE (some years ago one of our students
mentioned there could be a bug ...) -> a complete desaster, did not
work at all, results were different from vasp.5.4.4, found partly "random
results" for different machines and settings and startup times ... .
Problem identified and necessary fix: There is an accidental explicit
(re-)declaration of variable NTYP (already declared in the head of the
module at line 9!) in subroutine CONSTRAINED_M_INIT (at line 165). The
tragic consequence is: This (despite the previous declaration allowed)
second declaration overrides the previous definition locally for this
specific subroutine, making it a new local variable there which is in
particular uninitialized there (undefined value!!!). Depending on
platform, date, time, whatever it could at best contain a zero (what
would result in a non-execution of the loop DO NT=1,NTYP) but sometimes
it could have any value (also >0, >whatever) resulting in unpredictable
"random results" (in some cases even segmentation faults ...). The very
simple fix is just to remove NTYP from the declaration list in line 165,
i.e., replace the old (incorrect) statement
INTEGER NTYP, NIS, NT, N1LOW, N2LOW, N3LOW, N1HI, N2HI, N3H
by the new correct statement
INTEGER NIS, NT, N1LOW, N2LOW, N3LOW, N1HI, N2HI, N3HI
and everything will work fine again (for any KPAR and NCORE ...).
This bug was not present in vasp.5.x because it stems from a removal of
all implicit type declarations (in favor of "IMPLICIT NONE" and explicit type
declarations) when moving from vasp.5 to vasp.6 (one declaration too much).
I also stumbled over some other (less serious) bug (that should also be
fixed) in routine XML_WRITE_CONSTRAINED_M: There, on line 148, I found
some XML output call for "AM_CONSTR"
CALL XML_INCAR_V('M_CONSTR','F',IDUM,AM_CONSTR,CDUM,...
but I'm quite convinced that you wanted to write out "M_CONSTR" instead
(or not ??), so you should replace that then by (kill the "A" ... ;-))
CALL XML_INCAR_V('M_CONSTR','F',IDUM,M_CONSTR,CDUM,...
(and again the declaration of AM_CONSTR in line 140 can/must also
be removed, i.e. it should only read "REAL(q) RDUM" then ... [?]).