[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