[Wien] Some info on 1525-097 READ statement error during scf cycle

[Tianjiao Zhang]

Dear users,

(1) The following test was carried out on ibm sp3.
/
(2)
Console output error is something like:

/STOP  LAPW 2END
1525- 097A READ statement using decimal base input found the invalid 
digit '-' in the input file.  The program will recover by assuming a 
zero in its place.
STOP  SUMPARA END

My debug indicates the read error statement origining from sumpara.
/
(3) In my case, it's a pure type error in case.in2 (TOT->FOT).
Somewhat the code l2main.F does not check this input parameter when 
first reading it.  Later in statement writing output to 
case.clmvalup/dn, it can not pass the module check and the output in 
//case.clmvalup/dn gets "/NUMBER OF LM=-1". I really did not follow 
through where the LM=-1
is finally written.  (Wrting to case.vrespvalup seems not affected)


/(4) For intermediate parallel computation files such as 
//case.clmvalup_n, charge density and its info within the MT sphere is 
not written and read statments in sumpara just get //data //completely 
out of order.

(5.1) More precisely, the whole output from //case.clmvalup/dn is/
                TOTAL CHARGE DENSITY GENERATED BY
 hcp xx  in hcp xx  H     5.169480  5.169480  8.255660  781
 
   ATOM NUMBER = 1
   NUMBER OF LM=-1
 
 
 
 
 
 
   MIXED TOTAL CHARGE DENSITY IN INTERSTITIAL   NEW TOTAL CHARGE DENSITY
 
 NUMBER OF PW     0
(5.2) The head of /case.clmvalup_n /STARTs with
    VALENCE CHARGE DENSITY IN INTERSTITIAL
 
 NUMBER OF PW   510

/(6) The code does not stop in the present cycle until the next one, 
giving misleading errors in case.dayfile as

/**  lapw0 crashed!

(7)
This MIGHT be a useful followup to message /
Tue, 23 Mar10 2004 :18: 20+ 0800by David etc about read errors during scf
iteration.
//
/
So, proabaly some minimal and consistent check of the input file case.in2
during init_lapw can reduce this kind of errors.

Hope this can be useful in debugging.

Sincerely,
Tianjiao