I don't have troubles with charge.f, see my next mail I just have to cook and eat my dinner first
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 [[email protected]] im Auftrag von Laurence Marks [[email protected]] Gesendet: Montag, 30. Dezember 2024 19:09 An: A Mailing list for WIEN2k users Betreff: Re: [Wien] ifort classic compiler now discontinued in one-api 2025.0 online repositories Probably better to include a space after: sed 's/ simd / parallel do /' charge.f_old > charge.f N.B., I have not checked the accuracy. While dnrm2 is very accurate, Intel's ddot is not for whatever reason. ___ Emeritus Professor Laurence Marks (Laurie) Department of Materials Science and Engineering, Northwestern University www.numis.northwestern.edu<http://www.numis.northwestern.edu> "Research is to see what everybody else has seen, and to think what nobody else has thought" Albert Szent-Györgyi On Mon, Dec 30, 2024, 11:38 Laurence Marks <[email protected]<mailto:[email protected]>> wrote: Try this: cd $WIENROOT/SRC_Globals cp charge.f charge.f_old sed 's/ simd / parallel do/' charge.f_old > charge.f At least with my version of ifx (ifx (IFORT) 2021.1 Beta 20201113) the "$omp simd" lines fail even without -qopenmp. However, when they are converted to a straight parallel do they work fine. There are some pages noting issues if you search for "ifx omp simd". On Fri, Dec 27, 2024 at 11:49 AM Laurence Marks <[email protected]<mailto:[email protected]>> wrote: I will send a few variants of charge.f next week. The cleanest solution is probably to add to relevant routines something like #ifdef _IFX $NOOPTOMIZE #endif I don't have access at the moment to the ifx docu to determine what the right directives are. --- Emeritus Professor Laurence Marks (Laurie) www.numis.northwestern.edu<http://www.numis.northwestern.edu> https://scholar.google.com/citations?user=zmHhI9gAAAAJ&hl=en "Research is to see what everybody else has seen, and to think what nobody else has thought" Albert Szent-Györgyi On Fri, Dec 27, 2024, 16:04 Gavin Abo <[email protected]<mailto:[email protected]>> wrote: The problem I've encountered with using -standard-semantics is that only lapw0 and lapw1 don't compile with unreferenced errors (e.g., libxc). Currently, a work around seems to be to recompile lapw0 and lapw1 with -O0 without -standard-semantics. I tried removing -pad but the segmentation error still happens: username@computername:~/WIEN2k/SRC_dstart$ grep 'OPT =' Makefile FOPT = -O -FR -mp1 -w -prec_div -pc80 -ip -DINTEL_VML -traceback -assume buffered_io -I$(MKLROOT)/include $(OMP_SWITCH) FPOPT = -O -FR -mp1 -w -prec_div -pc80 -ip -DINTEL_VML -traceback -assume buffered_io -I$(MKLROOT)/include $(OMP_SWITCHP) $(OMP_SWITCHP) username@computername:~/WIEN2k/SRC_dstart$ make ... make dstart FORT=ifx FFLAGS=' -O -FR -mp1 -w -prec_div -pc80 -ip -DINTEL_VML -traceback -assume buffered_io -I/opt/intel/oneapi/mkl/2025.0/include -qopenmp ' make[1]: Entering directory '/home/username/WIEN2k/SRC_dstart' ... ifx -O -FR -mp1 -w -prec_div -pc80 -ip -DINTEL_VML -traceback -assume buffered_io -I/opt/intel/oneapi/mkl/2025.0/include -qopenmp -c charge.f #0 0x0000615e21717b41 #1 0x0000615e2177c457 #2 0x0000615e2177c585 #3 0x0000071d83e45320 #4 0x0000615e2089cba0 #5 0x0000615e22ab0f28 #6 0x0000615e21089b27 #7 0x0000615e2108966c #8 0x0000615e2125b59a #9 0x0000615e20fc7253 #10 0x0000615e20e7e752 #11 0x0000615e20c0baac #12 0x0000615e20c0ac9d #13 0x0000615e20c0abf1 #14 0x0000615e20febfe2 #15 0x0000615e20bb0c1c #16 0x0000615e208f2e94 #17 0x0000615e208f2cb9 #18 0x0000615e20869241 #19 0x0000615e20868f71 #20 0x0000615e2097f34a #21 0x0000615e2097f121 #22 0x0000615e20e9c8a9 #23 0x0000615e216b4cfa #24 0x0000615e216b2a37 #25 0x0000615e2165e64b #26 0x0000615e2183a704 #27 0x0000071d83e2a1ca #28 0x0000071d83e2a28b __libc_start_main + 139 #29 0x0000615e2149519e charge.f: error #5633: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error. compilation aborted for charge.f (code 3) ... Gavin __________________ Wien mailing list [email protected]<mailto:[email protected]> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/[email protected]/index.html -- Emeritus Professor Laurence Marks (Laurie) Northwestern University Webpage<http://www.numis.northwestern.edu> and Google Scholar link<http://scholar.google.com/citations?user=zmHhI9gAAAAJ&hl=en> "Research is to see what everybody else has seen, and to think what nobody else has thought", Albert Szent-Györgyi _______________________________________________ Wien mailing list [email protected] http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/[email protected]/index.html
