<div dir="auto"><div><div>Ksum3.f is short, please recheck.</div><div dir="auto"><br></div><div dir="auto">Note, these are not coding errors. The message from Intel indicates that their compiler messed up. How...unclear. It would be good to report the issue to Intel.</div><div dir="auto"><br></div><div dir="auto">Try -O1, in other words reduce the optimization until the issue goes away.</div><div><br></div><div data-smartmail="gmail_signature">---<br>Emeritus Professor Laurence Marks (Laurie)<br><a href="http://www.numis.northwestern.edu">www.numis.northwestern.edu</a><br><a href="https://scholar.google.com/citations?user=zmHhI9gAAAAJ&hl=en">https://scholar.google.com/citations?user=zmHhI9gAAAAJ&hl=en</a><br>"Research is to see what everybody else has seen, and to think what nobody else has thought" Albert Szent-Györgyi</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 27, 2024, 16:12 Michael Fechtelkord via Wien <<a href="mailto:wien@zeus.theochem.tuwien.ac.at">wien@zeus.theochem.tuwien.ac.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Peter,<br>
<br>
<br>
I isolated the two subroutines causing the error.<br>
<br>
<br>
Those are SUBROUTINE CHARGEF and subroutine KSum3, which are the two <br>
longest subroutines ( 106 and 122 lines). All others are quite short and <br>
compile without errors. I assume the length leads to the crashes.<br>
<br>
I will try also another computer to exclude hardware issues.<br>
<br>
<br>
Best regards,<br>
<br>
Michael<br>
<br>
<br>
<br>
Am 27.10.2024 um 20:04 schrieb Peter Blaha:<br>
> charge.f is in SRC_Globals (in the other SRC_* dirs there should only <br>
> be a softlink to it.<br>
><br>
> charge.f contains several subroutines/functions. Maybe this fact or <br>
> that there are too many may cause the problem.<br>
><br>
> The way to debug is to split this charge.f into several files (maybe <br>
> use "bisection") and compile each part individually until the problem <br>
> can be located (or is gone).<br>
><br>
> In SRC_Globals split it into two parts and<br>
><br>
> mpiifx -O3 -xAVX2 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -<br>
> traceback -assume buffered_io -I/opt/intel/oneapi/mkl/2025.0/include -<br>
> qopenmp -DParallel -c c1.f<br>
><br>
> and<br>
><br>
> mpiifx -O3 -xAVX2 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -<br>
> traceback -assume buffered_io -I/opt/intel/oneapi/mkl/2025.0/include -<br>
> qopenmp -DParallel -c c2.f<br>
><br>
><br>
> If a problem occurs, split further ...<br>
> ---------------------------------------------<br>
> SearchZ.F (was added by L. Marks)<br>
><br>
> maybe one needs a "external RHOSTM" statement at the beginning.<br>
><br>
> > call RTBIS(RHOSTM,X1,X2,XACC,CTarget,ISTM,RT)<br>
> > ---------------------------^<br>
><br>
> Rhostm is a function, passed into a subroutine ....<br>
><br>
><br>
> Am 27.10.2024 um 19:17 schrieb Michael Fechtelkord via Wien:<br>
>> Dear all,<br>
>><br>
>><br>
>> the libxc problem does not longer exist. I used the newest ifx <br>
>> version now. Most parts of WIEN2k compile without problems. Two <br>
>> source files still make problems.<br>
>><br>
>><br>
>> 1) charge.f (in different source directories, same error always)<br>
>><br>
>> mpiifx -O3 -xAVX2 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML - <br>
>> traceback -assume buffered_io -I/opt/intel/oneapi/mkl/2025.0/include <br>
>> - qopenmp -DParallel -c charge.f<br>
>> #0 0x000000000310cce1<br>
>> #1 0x00000000031715d7<br>
>> #2 0x0000000003171705<br>
>> #3 0x0000148436a57980<br>
>> #4 0x0000000002291d60<br>
>> #5 0x00000000044a6048<br>
>> #6 0x0000000002a7aa37<br>
>> #7 0x0000000002a7a57c<br>
>> #8 0x0000000002c4c4ca<br>
>> #9 0x00000000029b8173<br>
>> #10 0x00000000028743b2<br>
>> #11 0x000000000260103c<br>
>> #12 0x000000000260022d<br>
>> #13 0x0000000002600181<br>
>> #14 0x00000000029ddd62<br>
>> #15 0x00000000025a617c<br>
>> #16 0x00000000022e8064<br>
>> #17 0x00000000022e7e89<br>
>> #18 0x000000000225e401<br>
>> #19 0x000000000225e131<br>
>> #20 0x000000000237461a<br>
>> #21 0x00000000023743f1<br>
>> #22 0x00000000028924e9<br>
>> #23 0x00000000030a9e9a<br>
>> #24 0x00000000030a7bd7<br>
>> #25 0x00000000030537eb<br>
>> #26 0x000000000322f884<br>
>> #27 0x0000148436a40eec<br>
>> #28 0x0000148436a40fb5 __libc_start_main + 135<br>
>> #29 0x0000000002e8a34e<br>
>><br>
>> charge.f: error #5633: **Internal compiler error: segmentation <br>
>> violation signal raised** Please report this error along with the <br>
>> circumstances in which it occurred in a So<br>
>> ftware Problem Report. Note: File and line given may not be explicit <br>
>> cause of this error.<br>
>> compilation aborted for charge.f (code 3)<br>
>><br>
>> 2) SearchZ_tmp_.F<br>
>><br>
>> ifx -O3 -xAVX2 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML - <br>
>> traceback -assume buffered_io -I/opt/intel/oneapi/mkl/2025.0/include <br>
>> -c SearchZ_tmp_.F<br>
>> #0 0x000000000310cce1<br>
>> #1 0x00000000031715d7<br>
>> #2 0x000000000315cfda<br>
>> #3 0x0000000003073fb6<br>
>> #4 0x00000000030c411e<br>
>> #5 0x00000000031063e6<br>
>> #6 0x000000000310002f<br>
>> #7 0x00000000030fe080<br>
>> #8 0x00000000030fd24d<br>
>> #9 0x00000000031bf819<br>
>> #10 0x00000000031bfe05<br>
>> #11 0x00000000031bcff8<br>
>> #12 0x00000000031bf819<br>
>> #13 0x00000000031bfe05<br>
>> #14 0x00000000031c2909<br>
>> #15 0x00000000031bf819<br>
>> #16 0x00000000031bcc3e<br>
>> #17 0x00000000031bf819<br>
>> #18 0x000000000305397b<br>
>> #19 0x0000000003053317<br>
>> #20 0x000000000322f884<br>
>> #21 0x000015481a240eec<br>
>> #22 0x000015481a240fb5 __libc_start_main + 135<br>
>> #23 0x0000000002e8a34e<br>
>><br>
>> SearchZ_tmp_.F(114): error #5623: **Internal compiler error: internal <br>
>> abort** Please report this error along with the circumstances in <br>
>> which it occurred in a Software Prob<br>
>> lem Report. Note: File and line given may not be explicit cause of <br>
>> this error.<br>
>> call RTBIS(RHOSTM,X1,X2,XACC,CTarget,ISTM,RT)<br>
>> ---------------------------^<br>
>> compilation aborted for SearchZ_tmp_.F (code 3)<br>
>><br>
>><br>
>> Best regards,<br>
>><br>
>> Michael<br>
>><br>
>><br>
>><br>
>><br>
>> Am 27.10.2024 um 15:21 schrieb Michael Fechtelkord via Wien:<br>
>>> Dear all,<br>
>>><br>
>>><br>
>>> just a few new results and informatuion using the Intel ifx <br>
>>> compiler. ELPA, FFTW, LIBXC and MPICH compile fine and also check <br>
>>> procedure shows no errors.<br>
>>><br>
>>><br>
>>> WIEN2k seems to have problems when using no explicit types for <br>
>>> variables. A short summary of the errors all in libxc_mod.F:<br>
>>><br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(4): error #7002: Error in opening <br>
>>> the compiled module file. Check INCLUDE paths. [XC_F03_LIB_M]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(9): error #6457: This derived type <br>
>>> name has not been declared. [XC_F03_FUNC_T]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(10): error #6457: This derived <br>
>>> type name has not been declared. [XC_F03_FUNC_INFO_T]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(22): error #6404: This name does <br>
>>> not have a type, and must have an explicit type. [XC_FUNC_X]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(22): error #6404: This name does <br>
>>> not have a type, and must have an explicit type. [XC_UNPOLARIZED]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(23): error #6404: This name does <br>
>>> not have a type, and must have an explicit type. [XC_FUNC_C]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(25): error #6404: This name does <br>
>>> not have a type, and must have an explicit type. [XC_POLARIZED]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(38): error #6404: This name does <br>
>>> not have a type, and must have an explicit type. [XC_INFO_C]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(38): error #6404: This name does <br>
>>> not have a type, and must have an explicit type. [XC_F03_FUNC_GET_INFO]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(39): error #6404: This name does <br>
>>> not have a type, and must have an explicit type. [XC_INFO_X]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(40): error #6404: This name does <br>
>>> not have a type, and must have an explicit type. <br>
>>> [XC_F03_FUNC_INFO_GET_FLAGS]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(4): error #7002: Error in opening <br>
>>> the compiled module file. Check INCLUDE paths. [XC_F03_LIB_M]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(9): error #6457: This derived type <br>
>>> name has not been declared. [XC_F03_FUNC_T]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(10): error #6457: This derived <br>
>>> type name has not been declared. [XC_F03_FUNC_INFO_T]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(22): error #6404: This name does <br>
>>> not have a type, and must have an explicit type. [XC_FUNC_X]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(22): error #6404: This name does <br>
>>> not have a type, and must have an explicit type. [XC_UNPOLARIZED]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(23): error #6404: This name does <br>
>>> not have a type, and must have an explicit type. [XC_FUNC_C]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(25): error #6404: This name does <br>
>>> not have a type, and must have an explicit type. [XC_POLARIZED]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(38): error #6404: This name does <br>
>>> not have a type, and must have an explicit type. [XC_INFO_C]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(38): error #6404: This name does <br>
>>> not have a type, and must have an explicit type. [XC_F03_FUNC_GET_INFO]<br>
>>> SR<a href="https://www.google.com/maps/search/C_lapw0%2Fcompile.msg:l?entry=gmail&source=g">C_lapw0/compile.msg:l</a>ibxc_mod.F(39): error #6404: This name does <br>
>>> not have a type, and must have an explicit type. [XC_INFO_X]<br>
>>> SRC_lapw0/compile.msg:libxc_mod.F(40): error #6404: This name does <br>
>>> not have a type, and must have an explicit type. <br>
>>> [XC_F03_FUNC_INFO_GET_FLAGS]<br>
>>><br>
>>> In addition Segmenation violation signals occur in several modules.<br>
>>><br>
>>><br>
>>> Best regards<br>
>>><br>
>>> Michael<br>
>>><br>
><br>
-- <br>
Dr. Michael Fechtelkord<br>
<br>
Institut für Geologie, Mineralogie und Geophysik<br>
Ruhr-Universität Bochum<br>
Universitätsstr. 150<br>
D-44780 Bochum<br>
<br>
Phone: +49 (234) 32-24380<br>
Fax: +49 (234) 32-04380<br>
Email: <a href="mailto:Michael.Fechtelkord@ruhr-uni-bochum.de" target="_blank" rel="noreferrer">Michael.Fechtelkord@ruhr-uni-bochum.de</a><br>
Web Page: <br>
<a href="https://www.ruhr-uni-bochum.de/kristallographie/kc/mitarbeiter/fechtelkord/" rel="noreferrer noreferrer" target="_blank">https://www.ruhr-uni-bochum.de/kristallographie/kc/mitarbeiter/fechtelkord/</a><br>
<br>
_______________________________________________<br>
Wien mailing list<br>
<a href="mailto:Wien@zeus.theochem.tuwien.ac.at" target="_blank" rel="noreferrer">Wien@zeus.theochem.tuwien.ac.at</a><br>
<a href="http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien" rel="noreferrer noreferrer" target="_blank">http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien</a><br>
SEARCH the MAILING-LIST at: <a href="http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html" rel="noreferrer noreferrer" target="_blank">http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html</a><br>
</blockquote></div></div></div>