[Wien] LAPW0 -- again

Fecher, Gerhard fecher at uni-mainz.de
Fri Jul 11 09:39:25 CEST 2025


Hallo Michael,
sorry  I had no time to go into more detail, just some short remark:
>From  mixer.F the cleanest solution should be found from (using correct numbers for the format lines):

!.....WRITE NEW DENSITY 
!                                                                       
!       REWIND 11
9912    continue
        lmmaxx=0  
        do jatom=1,nat
                lmmaxx=max0(lmmaxx,lmmax(jatom))
        enddo                                                 
        WRITE(51,1970) ISCF                                               
        WRITE(51,78) TITLE(1:20),LATTIC,ALAT(1),ALAT(2),ALAT(3),JRI(1)
        WRITE(51,77) lmmaxx
...
...
 77     FORMAT(' LM-max:',i4) 

** Note 1:

Probably one can use instead of the do loop also maxval() and simply replace the WRITE() lmmax line by
(note 77 is already used in atom_write of dstart)
...
        WRITE(51,70) MAXVAL(lmmax)
...
...
 70     FORMAT(' LM-max:',i4) 

** Note 2:
There is a test programm for the largest size of arrays on
https://fortran-lang.discourse.group/t/how-large-can-an-automatic-array-on-the-heap-be/4934
with some interesting discussions.

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
________________________________________
Von: Wien [wien-bounces at zeus.theochem.tuwien.ac.at] im Auftrag von Michael Fechtelkord [Michael.Fechtelkord at ruhr-uni-bochum.de]
Gesendet: Donnerstag, 10. Juli 2025 23:13
An: A Mailing list for WIEN2k users
Betreff: Re: [Wien] LAPW0 -- again

Hello Peter,


thanks for your answer. I tried your suggestions.


First I tried

  LM-max: 261 in case.clmsum,


=> lapw0 crashed with the usual segmentation fault,


however  using

  LM-max: 121 in case.clmsum


=> lapw0 ends normally


Best regards,

Michael


Am 10.07.2025 um 21:11 schrieb Peter Blaha:
> No, the line in atom_write.f is not correct.
>
>           write(51,2022) lmmax(ia+1)
>
> It would fail for a one-atom cell and is wrong when the number of LM
> values for the second atom is not the largest of all.
>
> Instead, use:
>
>           write(51,2022) ncom1
>
> ncom1 is set in init.F to the maximum LM values of all atoms.
> ------------------------------
>
> It is probably a stacksize problem in lapw0.
>
> If lmmaxx is not present in case.clmsum,   lmmaxx=ncom (set to 261 in
> param.inc). Presumably this is too large and breaks something for omp
> in ifx, since this lmaxx is used to allocate large arrays.
>
> As you have tested, small lmmax values seem to work. However, for low
> symmetry this lmmax value could reach 49 (49 LM combinations up to
> L=6, i.e. 7*7) or even 121  (if you manually increase the LM-list in
> case.in2 up to L=10  (11*11)).
>
> Could you just set   lmmaxx=121 in case.clmsum and run lapw0 to check
> if it still runs. If it fails, please try   49  instead.
>
> Thanks for all your debugging. I do not have  ifx installed yet .....
>
>
> Am 10.07.2025 um 16:03 schrieb Michael Fechtelkord:
>> I added two lines in/atom_write.f /in /SRC_dstart/ and commented one
>> line (changes in bold):
>>
>>
>>
>>       if (ia.eq.1) then
>>      ! if(myid .eq. 0)then
>>          write(51,1970) iscf
>>          write(51,78) title,lattic,aa,bb,cc,jrj(1)
>> *#      write(51,77)
>>          write(51,2022) lmmax(ia+1)*
>>      ! end if
>>       end if
>>      ! if(myid .eq. 0)then
>>       write(51,1990) ia
>>       write(51,2771) lmmax(ia)
>>
>>       do  lm1=1,lmmax(ia)
>>
>>          write(51,2011) lm(1,lm1,ia),lm(2,lm1,ia)
>>          write(51,2021) ( rholm(j,lm1), j=1,jrj(ia) )
>>          write(51,2031)
>>       !enddo
>>       enddo
>>       write(51,2033)
>>     !  end if
>> !
>>   77   format(1x,9(f9.7))
>>   78   format(1x,a20,a4,3f10.6,i5)
>>   1970 format(3x,'             TOTAL CHARGE DENSITY GENERATED ',     &
>>         'BY',i3,'. ITERATION (NORM: CLM=CLM*R*R)')
>>   1980  format(3x)
>>   2771  format(3x,'NUMBER OF LM',I3//)
>> * 2022  FORMAT(1x,'LM-max:'1x,I3)*
>>
>>
>> Maybe the experts can quickly check, if I did all correctly .. Thanks
>> in advance!
>>
>> Am 10.07.2025 um 12:44 schrieb Fecher, Gerhard:
>>> Fine that it works also for other cases
>>>
>>> you have to check in  atom_write.f of dstart
>>>
>>> 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
>>> ________________________________________
>>> Von: Wien [wien-bounces at zeus.theochem.tuwien.ac.at] im Auftrag von
>>> Michael Fechtelkord [Michael.Fechtelkord at ruhr-uni-bochum.de]
>>> Gesendet: Donnerstag, 10. Juli 2025 12:29
>>> An: A Mailing list for WIEN2k users
>>> Betreff: Re: [Wien] LAPW0 -- again
>>>
>>> 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/
>>>
>>> _______________________________________________
>>> 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
>>> _______________________________________________
>>> 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/
>>
>>
>> _______________________________________________
>> 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/

_______________________________________________
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


More information about the Wien mailing list