[Wien] LAPW0 -- again

[Michael Fechtelkord]

Hello Gerhard,


I just tried your solution on my MgF2 case. lapw0 runs here without any 
problems when I insert LM-MAX into the initial case.clmsum

                 TOTAL CHARGE DENSITY GENERATED BY  0. ITERATION (NORM: 
CLM=CLM*R*R)
  MgF2                P     8.736207  8.736207  5.767446  781

    ATOMNUMBER =  1
    NUMBER OF LM 10


    CLM(R) FOR L  0   M= 0

...

adding

  LM-max:  16

in the third line makes lapw0 run, even with omp_num_threads larger than 1

                 TOTAL CHARGE DENSITY GENERATED BY  0. ITERATION (NORM: 
CLM=CLM*R*R)
  MgF2                P     8.736207  8.736207  5.767446  781
  LM-max:  16
    ATOMNUMBER =  1
    NUMBER OF LM 10


    CLM(R) FOR L  0   M= 0

....

It should be easy to add that line by dstart in the initial *.clmsum.


Best regards,

Michael


Am 10.07.2025 um 11:54 schrieb Fecher, Gerhard:
> Dear all,
> I am curious how lapw0 should know in which cycle it is,
> there must be a difference between the first and all other cycles,
> that means something is not or not completely initialised in the 1st cycle.
> There are not too many files to be inspected that are used by lapw0 as input,
> case.clsum contains in the first line the number of the iteration, which is "0." in the first cycle and "1." after the first cycle, and so on .....
>
> However, there is another difference:
> after dstart, the third line of case.clmsum is empty
>                  TOTAL CHARGE DENSITY GENERATED BY  0. ITERATION
>   Li a_exp            B     6.632941  6.632941  6.632941  781
>
>     ATOMNUMBER =  1
>     NUMBER OF LM  5
> ...
>
> whereas after the first cycle it is, in my simple test case
>                  TOTAL CHARGE DENSITY GENERATED BY  1. ITERATION
>   Li a_exp            B     6.632941  6.632941  6.632941  781
>   LM-max:   5
>     ATOMNUMBER =  1
>     NUMBER OF LM  5
> ...
>
> Now, when I insert ' LM-max:   5'  into the empty line of a fresh case.clmsum after dstart, then lapw0 runs without problem altready in the first cycle.
> The line with LM-max is also missing after dstart in the case.clmup/dn files of spin polarised cakculations, but there it seems that it doesn't matter .
>
> Solution, if the missing line is the cause for the segmentation faults (maybe through wrong array size by allocation):
> 1) dstart writes the LM-max line with the correct value into case.clmsum
> or
> 2) lapw0  needs to be inspected in more detail:
> lmmax ix used for various allocations, maybe that is the reason why something goes wrong if the empty input line is interpreted wrong
> check in lapw0 line 336 ff  (and the format lines)
> ! READ SCFDATA UNTIL BOTTOM AND INCREASE CYCLENUMBER BY ONE
>        if(myid.eq.0) then
>           READ(8,2044)  ISCF
>           read(8,2043) lmmaxx
>        endif
> #ifdef Parallel
>           call MPI_Bcast(iscf,1,MPI_INTEGER,0,MPI_COMM_WORLD,ierr)
>           call MPI_Bcast(lmmaxx,1,MPI_INTEGER,0,MPI_COMM_WORLD,ierr)
> #endif
>        ISCF=ISCF+1
>        if(lmmaxx.eq.0) lmmaxx=ncom
>        IF(ISCF.GT.999) ISCF=1
> ...
> (note: ncom=261 from params.inc)
>
> It might also be that trying to read an integer from the empty third line causes also later some other problems with the input, which was not a problem with ifort or gfortran but appears in ifx
>
> (It is not known that the old comments about the OMP problems in lapw0 whether they appeared only in the 1st or also in other cycles,
> however from the comments in lapw0.F and the changes file in SRC_lapw0 from 2021, it seems to be not just a problem of ifx)
>
> Ciao
> Gerhard
>
> DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
> "I think the problem, to be quite honest with you,
> is that you have never actually known what the question is."
>
> ====================================
> Dr. Gerhard H. Fecher
> Institut of Physics
> Johannes Gutenberg - University
> 55099 Mainz
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

-- 
Dr. Michael Fechtelkord

Institut für Geologie, Mineralogie und Geophysik
Ruhr-Universität Bochum
Universitätsstr. 150
D-44780 Bochum

Phone: +49 (234) 32-24380
Fax:  +49 (234) 32-04380
Email: Michael.Fechtelkord at ruhr-uni-bochum.de
Web Page: https://www.ruhr-uni-bochum.de/kristallographie/kc/mitarbeiter/fechtelkord/