[Wien] LAPW0 -- again
Michael Fechtelkord
Michael.Fechtelkord at ruhr-uni-bochum.de
Fri Jul 11 15:22:55 CEST 2025
Hello all,
I did the following now, which is the easiest .. I used the original
SRC_dstart FORTRAN files (no changes in atomwrite.f) BUT
I changed param.inc in SRC_lapw0. I changed the line
PARAMETER (NCOM= 261) !181
to
PARAMETER (NCOM= 121) !181
according to the recommendations of Peter. param.inc in SRC_dstart has
already NCOM= 121 but it seems the higher value of 261 from the lapw0
param.inc is used as start value when the 3rd line in case.clmsum is empty.
No further lapw0 seg fault crashes occur. I hope that change is ok and
would be a solution to get over the lapw0 seg fault crash problem.
Best regards,
Michael
Am 11.07.2025 um 09:39 schrieb Fecher, Gerhard:
> 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
> _______________________________________________
> 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/
More information about the Wien
mailing list