March 2021 - Ecp-aurora-sdk-discuss - mailman3.cels.anl.gov

Re: [Ecp-aurora-sdk-discuss] New version of mpich on JLSE
by Willmore, Frank Ted 26 Mar '21

26 Mar '21

Colleen, thank you, you are indeed correct. I've been trying to reconcile in my mind some of the differences between our JLSE versions and the public versions, upon which the spack installer is based. The wrappers are really different. Hopefully these will eventually converge. A good weekend to all! Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Bertoni, Colleen <bertoni(a)anl.gov> Sent: Wednesday, March 24, 2021 6:31 PM To: ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov>; Chan-nui, Christopher <christopher.chan-nui(a)intel.com>; Willmore, Frank Ted <willmore(a)anl.gov> Subject: Re: New version of mpich on JLSE Could you try `MPICH_FC=ifx` (or maybe `MPICH_FC=`which ifx`) instead of `FC=which ifx`? I actually thought `MPICH_FC` was the way to specify ifx (or mpif90 -fc=ifx). Thanks, Colleen ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Wednesday, March 24, 2021 6:22 PM To: ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov>; Chan-nui, Christopher <christopher.chan-nui(a)intel.com> Subject: Re: [Ecp-aurora-sdk-discuss] New version of mpich on JLSE I noticed that the mpifort wrapper will always use ifort, even if FC=ifx is specified: 熊俊傑@jlselogin5:~/environments/e4s-oneapi$ which ifx /soft/restricted/CNDA/modulefiles/oneapi/bin/ifx 熊俊傑@jlselogin5:~/environments/e4s-oneapi$ FC=`which ifx` mpifort -show ifort -g -L/opt/neo/release/2020.10.05/lib64 -Wl,-z,now -I/soft/restricted/CNDA/mpich/drop39.2/mpich-ofi-sockets-icc-debug-gen9-drop39/include -I/soft/restricted/CNDA/mpich/drop39.2/mpich-ofi-sockets-icc-debug-gen9-drop39/include -L/soft/restricted/CNDA/mpich/drop39.2/mpich-ofi-sockets-icc-debug-gen9-drop39/lib -lmpifort -Wl,-rpath -Wl,/soft/restricted/CNDA/mpich/drop39.2/mpich-ofi-sockets-icc-debug-gen9-drop39/lib -Wl,--enable-new-dtags -lmpi Is this intended? Do all MPI codes with fortran need to be built with ifort, or is it possible to use ifx? Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Chan-nui, Christopher via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Wednesday, March 24, 2021 3:16 PM To: ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Subject: [Ecp-aurora-sdk-discuss] New version of mpich on JLSE Hello, We are pleased to announce that an update to mpich, drop 39.2, has been deployed on JLSE. module use /soft/restricted/CNDA/modulefiles module avail mpi/aurora_mpich Important: ATS nodes do not currently use GPU acceleration. Release Notes * Compiled using oneAPI Intel C/C++ compilers (icx and icpx) Details * Fixed library dependency issues * Added native binary compilation for GPU kernels to improve load times * Bug fixes -- Christopher Chan-Nui christopher.chan-nui(a)intel.com

1 0

Preview6 DL Frameworks deployed in the JLSE
by Ramer, Rebecca 25 Mar '21

25 Mar '21

Hi, We would like to announce availability of the preview 6 releases of the pytorch and tensorflow deep learning framework modules for use in the JLSE. The alpha 1 update ATS preview 6 tensorflow and pytorch modules provide python 3.7 based environments. The modules provide the same environment as the default oneapi module except for the version of the dpcpp compiler. Details, including how to setup and use the python environments can be viewed on the wiki, see: https://wiki.jlse.anl.gov/display/inteldga/Alpha1+update+-+ATS+Preview+6+Py… and https://wiki.jlse.anl.gov/display/inteldga/Alpha1+update+-+ATS+Preview+6+Te… Any feedback is welcome. Rebecca Ramer rebecca.ramer(a)intel.com

1 0

Re: [Ecp-aurora-sdk-discuss] New version of mpich on JLSE
by Bertoni, Colleen 24 Mar '21

24 Mar '21

Could you try `MPICH_FC=ifx` (or maybe `MPICH_FC=`which ifx`) instead of `FC=which ifx`? I actually thought `MPICH_FC` was the way to specify ifx (or mpif90 -fc=ifx). Thanks, Colleen ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Wednesday, March 24, 2021 6:22 PM To: ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov>; Chan-nui, Christopher <christopher.chan-nui(a)intel.com> Subject: Re: [Ecp-aurora-sdk-discuss] New version of mpich on JLSE I noticed that the mpifort wrapper will always use ifort, even if FC=ifx is specified: 熊俊傑@jlselogin5:~/environments/e4s-oneapi$ which ifx /soft/restricted/CNDA/modulefiles/oneapi/bin/ifx 熊俊傑@jlselogin5:~/environments/e4s-oneapi$ FC=`which ifx` mpifort -show ifort -g -L/opt/neo/release/2020.10.05/lib64 -Wl,-z,now -I/soft/restricted/CNDA/mpich/drop39.2/mpich-ofi-sockets-icc-debug-gen9-drop39/include -I/soft/restricted/CNDA/mpich/drop39.2/mpich-ofi-sockets-icc-debug-gen9-drop39/include -L/soft/restricted/CNDA/mpich/drop39.2/mpich-ofi-sockets-icc-debug-gen9-drop39/lib -lmpifort -Wl,-rpath -Wl,/soft/restricted/CNDA/mpich/drop39.2/mpich-ofi-sockets-icc-debug-gen9-drop39/lib -Wl,--enable-new-dtags -lmpi Is this intended? Do all MPI codes with fortran need to be built with ifort, or is it possible to use ifx? Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Chan-nui, Christopher via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Wednesday, March 24, 2021 3:16 PM To: ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Subject: [Ecp-aurora-sdk-discuss] New version of mpich on JLSE Hello, We are pleased to announce that an update to mpich, drop 39.2, has been deployed on JLSE. module use /soft/restricted/CNDA/modulefiles module avail mpi/aurora_mpich Important: ATS nodes do not currently use GPU acceleration. Release Notes * Compiled using oneAPI Intel C/C++ compilers (icx and icpx) Details * Fixed library dependency issues * Added native binary compilation for GPU kernels to improve load times * Bug fixes -- Christopher Chan-Nui christopher.chan-nui(a)intel.com

1 0

Re: [Ecp-aurora-sdk-discuss] New version of mpich on JLSE
by Willmore, Frank Ted 24 Mar '21

24 Mar '21

I noticed that the mpifort wrapper will always use ifort, even if FC=ifx is specified: 熊俊傑@jlselogin5:~/environments/e4s-oneapi$ which ifx /soft/restricted/CNDA/modulefiles/oneapi/bin/ifx 熊俊傑@jlselogin5:~/environments/e4s-oneapi$ FC=`which ifx` mpifort -show ifort -g -L/opt/neo/release/2020.10.05/lib64 -Wl,-z,now -I/soft/restricted/CNDA/mpich/drop39.2/mpich-ofi-sockets-icc-debug-gen9-drop39/include -I/soft/restricted/CNDA/mpich/drop39.2/mpich-ofi-sockets-icc-debug-gen9-drop39/include -L/soft/restricted/CNDA/mpich/drop39.2/mpich-ofi-sockets-icc-debug-gen9-drop39/lib -lmpifort -Wl,-rpath -Wl,/soft/restricted/CNDA/mpich/drop39.2/mpich-ofi-sockets-icc-debug-gen9-drop39/lib -Wl,--enable-new-dtags -lmpi Is this intended? Do all MPI codes with fortran need to be built with ifort, or is it possible to use ifx? Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Chan-nui, Christopher via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Wednesday, March 24, 2021 3:16 PM To: ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Subject: [Ecp-aurora-sdk-discuss] New version of mpich on JLSE Hello, We are pleased to announce that an update to mpich, drop 39.2, has been deployed on JLSE. module use /soft/restricted/CNDA/modulefiles module avail mpi/aurora_mpich Important: ATS nodes do not currently use GPU acceleration. Release Notes * Compiled using oneAPI Intel C/C++ compilers (icx and icpx) Details * Fixed library dependency issues * Added native binary compilation for GPU kernels to improve load times * Bug fixes -- Christopher Chan-Nui christopher.chan-nui(a)intel.com

1 0

New version of mpich on JLSE
by Chan-nui, Christopher 24 Mar '21

24 Mar '21

Hello, We are pleased to announce that an update to mpich, drop 39.2, has been deployed on JLSE. module use /soft/restricted/CNDA/modulefiles module avail mpi/aurora_mpich Important: ATS nodes do not currently use GPU acceleration. Release Notes * Compiled using oneAPI Intel C/C++ compilers (icx and icpx) Details * Fixed library dependency issues * Added native binary compilation for GPU kernels to improve load times * Bug fixes -- Christopher Chan-Nui christopher.chan-nui(a)intel.com

1 0

Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0
by Willmore, Frank Ted 22 Mar '21

22 Mar '21

I have verified that I can run autoconf 2.70. to generate a new configure script which runs successfully, at least for hypre. However, for building with spack, this will require tinkering with the sources after download, as the configure script generated by autoconf 2.69 ships with the software release, or alternatively asking packagers to update to autoconf 2.70 before generating their configure script, which is a bit of an ask. Thank you all for the helpful feedback, which helped me isolate the issue. Cheers, --Frank Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Romero, Nichols A. <naromero(a)anl.gov> Sent: Monday, March 22, 2021 11:43 AM To: Willmore, Frank Ted <willmore(a)anl.gov>; Bertoni, Colleen <bertoni(a)anl.gov>; Applencourt, Thomas <tapplencourt(a)anl.gov>; ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Subject: Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Frank, Sorry for not replying sooner. We had this problem with part of MCT (Fortran) which is part of E3SM. You might find the discussion here helpful. https://github.com/MCSclimate/MCT/pull/61 https://github.com/MCSclimate/MCT/pull/66 It does look like updating to autoconf 2.7 solved the issue for us. From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of "Willmore, Frank Ted via Ecp-aurora-sdk-discuss" <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Reply-To: "Willmore, Frank Ted" <willmore(a)anl.gov> Date: Thursday, March 18, 2021 at 5:35 PM To: "Bertoni, Colleen" <bertoni(a)anl.gov>, "Applencourt, Thomas" <tapplencourt(a)anl.gov>, ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Subject: Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Looking at the discussion, this make sense now. I'm trying to get spack to concretize with the 2.70 version, but it looks like it will need to rebuild a whole cascade of dependents. Also, for some reason, spack keeps re-writing 2.70 as 2.7. I'll try the 2.70 version and if it works, then it should be fine, otherwise I can work to define a reproducer. Thanks for looking at it! --Frank Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Bertoni, Colleen <bertoni(a)anl.gov> Sent: Thursday, March 18, 2021 4:47 PM To: Applencourt, Thomas <tapplencourt(a)anl.gov>; ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov>; Willmore, Frank Ted <willmore(a)anl.gov> Subject: Re: unfortunately named fortran compiler option -loopopt=0 Hi Frank, Yeah, I remember this discussion for Fortran before (https://community.intel.com/t5/Intel-Fortran-Compiler/ifx-2021-1-beta04-HPC…) This looks like C, though. Is it possible for you to send steps to reproduce? Thanks, Colleen ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Thursday, March 18, 2021 1:00 PM To: Applencourt, Thomas <tapplencourt(a)anl.gov>; ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov>; Willmore, Frank Ted <willmore(a)anl.gov> Subject: Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Hi-- I'm running into this same issue again. HDF5 will not configure because compilation is misinterpreting a flag: /soft/restricted/CNDA/mpich/drop39.1/mpich-ofi-sockets-icc-debug-gen9-drop39/bin/mpicc -o conftest -fPIC conftes t.c -loopopt=0 ... The culprit here is -loopopt, which is intended, presumably, for the compiler, but which is being passed to the linker which thinks it should link libloopopt (which isn't a thing). I had previously been able to work around this by using ifort instead of ifx, but ifort is no longer part of the distribution. Also, I can no longer view the discussion on the intel site at https://software.intel.com/en-us/comment/1952923#<https://software.intel.com/en-us/comment/1952923> · Has there been any activity on this issue? · Is this an issue that HDF5 and the other packages who include this option need to deal with individually in their build systems? · What is the intent of this option, will it continue to exist, and is there an alternative? Thanks, --Frank Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Tuesday, September 29, 2020 4:31 PM To: Applencourt, Thomas <tapplencourt(a)anl.gov>; ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Subject: Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Thank you for replying, Thomas and Brian. I tried adding the --best-effort flag, but ifx didn't understand it. Realizing there's an ifort executable available from the oneapi module, I pointed to that and was able to configure and build hypre with that. I'm driving this from spack, and am including the compiler stanza I used below, if anyone is interested. I hacked up my own version of the oneapi module which points to pure opensuse builds of gcc, etc. since spack refuses to cross-compile to a different OS. It's an ugly hack, but I can share if anyone is interested. - compiler: spec: intel(a)2020.09.15.001 paths: cc: icx cxx: icpx f77: ifort fc: ifort operating_system: opensuse_leap15 target: x86_64 modules: - /home/willmore/modulefiles/intel-oneapi/hacked environment: prepend_path: LD_LIBRARY_PATH: /home/willmore/lib:/soft/restricted/CNDA/sdk/2020.7.30.1/oneapi/compiler/2021.1-beta08/linux/compiler/lib/intel64_lin unset: [] extra_rpaths: [] Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Applencourt, Thomas <tapplencourt(a)anl.gov> Sent: Tuesday, September 29, 2020 2:15 PM To: ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov>; Willmore, Frank Ted <willmore(a)anl.gov> Subject: Re: unfortunately named fortran compiler option -loopopt=0 Hi Frank, >Would falling back to an older ifort version to build Fortran components be a reasonable option? This is not an `official remand way` just a workaround we implemented, but you can try to add `--best-effort` flags with `ifx`. It will fall back to `ifort` if something goes wrong. So maybe it can help you when waiting for an official fix. Thomas Applencourt Leadership Computing Facility Argonne National Laboratory Building 240 Office - 1.D.18 9700 S Cass Av., Lemont Il, 60439 (630) 252-0036 ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Tuesday, September 29, 2020 14:04 To: ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Subject: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Hi-- I've been bumping against a known issue with ifx, namely that ifx generates a flag "-loopopt=0" which is intended to be consumed by an internal component (xfortcom) but which causes ld to erroneously try to link liboopopt=0 instead, and thus causing configure to fail. I'm attempting to build hypre. More on the issue here: https://software.intel.com/en-us/comment/1952923#<https://software.intel.com/en-us/comment/1952923> When I configure, I get (among other things): /usr/bin/ld: cannot find -loopopt=0 error: linking to Fortran libraries from C fails Has anyone else here stumbled on this when compiling Fortran, and if so, how did you work around it? Would falling back to an older ifort version to build Fortran components be a reasonable option? Thanks, --Frank Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]>

1 0

Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0
by Romero, Nichols A. 22 Mar '21

22 Mar '21

Frank, Sorry for not replying sooner. We had this problem with part of MCT (Fortran) which is part of E3SM. You might find the discussion here helpful. https://github.com/MCSclimate/MCT/pull/61 https://github.com/MCSclimate/MCT/pull/66 It does look like updating to autoconf 2.7 solved the issue for us. From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of "Willmore, Frank Ted via Ecp-aurora-sdk-discuss" <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Reply-To: "Willmore, Frank Ted" <willmore(a)anl.gov> Date: Thursday, March 18, 2021 at 5:35 PM To: "Bertoni, Colleen" <bertoni(a)anl.gov>, "Applencourt, Thomas" <tapplencourt(a)anl.gov>, ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Subject: Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Looking at the discussion, this make sense now. I'm trying to get spack to concretize with the 2.70 version, but it looks like it will need to rebuild a whole cascade of dependents. Also, for some reason, spack keeps re-writing 2.70 as 2.7. I'll try the 2.70 version and if it works, then it should be fine, otherwise I can work to define a reproducer. Thanks for looking at it! --Frank Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Bertoni, Colleen <bertoni(a)anl.gov> Sent: Thursday, March 18, 2021 4:47 PM To: Applencourt, Thomas <tapplencourt(a)anl.gov>; ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov>; Willmore, Frank Ted <willmore(a)anl.gov> Subject: Re: unfortunately named fortran compiler option -loopopt=0 Hi Frank, Yeah, I remember this discussion for Fortran before (https://community.intel.com/t5/Intel-Fortran-Compiler/ifx-2021-1-beta04-HPC…) This looks like C, though. Is it possible for you to send steps to reproduce? Thanks, Colleen ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Thursday, March 18, 2021 1:00 PM To: Applencourt, Thomas <tapplencourt(a)anl.gov>; ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov>; Willmore, Frank Ted <willmore(a)anl.gov> Subject: Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Hi-- I'm running into this same issue again. HDF5 will not configure because compilation is misinterpreting a flag: /soft/restricted/CNDA/mpich/drop39.1/mpich-ofi-sockets-icc-debug-gen9-drop39/bin/mpicc -o conftest -fPIC conftes t.c -loopopt=0 ... The culprit here is -loopopt, which is intended, presumably, for the compiler, but which is being passed to the linker which thinks it should link libloopopt (which isn't a thing). I had previously been able to work around this by using ifort instead of ifx, but ifort is no longer part of the distribution. Also, I can no longer view the discussion on the intel site at https://software.intel.com/en-us/comment/1952923#<https://software.intel.com/en-us/comment/1952923> · Has there been any activity on this issue? · Is this an issue that HDF5 and the other packages who include this option need to deal with individually in their build systems? · What is the intent of this option, will it continue to exist, and is there an alternative? Thanks, --Frank Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Tuesday, September 29, 2020 4:31 PM To: Applencourt, Thomas <tapplencourt(a)anl.gov>; ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Subject: Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Thank you for replying, Thomas and Brian. I tried adding the --best-effort flag, but ifx didn't understand it. Realizing there's an ifort executable available from the oneapi module, I pointed to that and was able to configure and build hypre with that. I'm driving this from spack, and am including the compiler stanza I used below, if anyone is interested. I hacked up my own version of the oneapi module which points to pure opensuse builds of gcc, etc. since spack refuses to cross-compile to a different OS. It's an ugly hack, but I can share if anyone is interested. - compiler: spec: intel(a)2020.09.15.001 paths: cc: icx cxx: icpx f77: ifort fc: ifort operating_system: opensuse_leap15 target: x86_64 modules: - /home/willmore/modulefiles/intel-oneapi/hacked environment: prepend_path: LD_LIBRARY_PATH: /home/willmore/lib:/soft/restricted/CNDA/sdk/2020.7.30.1/oneapi/compiler/2021.1-beta08/linux/compiler/lib/intel64_lin unset: [] extra_rpaths: [] Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Applencourt, Thomas <tapplencourt(a)anl.gov> Sent: Tuesday, September 29, 2020 2:15 PM To: ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov>; Willmore, Frank Ted <willmore(a)anl.gov> Subject: Re: unfortunately named fortran compiler option -loopopt=0 Hi Frank, >Would falling back to an older ifort version to build Fortran components be a reasonable option? This is not an `official remand way` just a workaround we implemented, but you can try to add `--best-effort` flags with `ifx`. It will fall back to `ifort` if something goes wrong. So maybe it can help you when waiting for an official fix. Thomas Applencourt Leadership Computing Facility Argonne National Laboratory Building 240 Office - 1.D.18 9700 S Cass Av., Lemont Il, 60439 (630) 252-0036 ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Tuesday, September 29, 2020 14:04 To: ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Subject: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Hi-- I've been bumping against a known issue with ifx, namely that ifx generates a flag "-loopopt=0" which is intended to be consumed by an internal component (xfortcom) but which causes ld to erroneously try to link liboopopt=0 instead, and thus causing configure to fail. I'm attempting to build hypre. More on the issue here: https://software.intel.com/en-us/comment/1952923#<https://software.intel.com/en-us/comment/1952923> When I configure, I get (among other things): /usr/bin/ld: cannot find -loopopt=0 error: linking to Fortran libraries from C fails Has anyone else here stumbled on this when compiling Fortran, and if so, how did you work around it? Would falling back to an older ifort version to build Fortran components be a reasonable option? Thanks, --Frank Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]>

1 0

Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0
by Willmore, Frank Ted 18 Mar '21

18 Mar '21

Looking at the discussion, this make sense now. I'm trying to get spack to concretize with the 2.70 version, but it looks like it will need to rebuild a whole cascade of dependents. Also, for some reason, spack keeps re-writing 2.70 as 2.7. I'll try the 2.70 version and if it works, then it should be fine, otherwise I can work to define a reproducer. Thanks for looking at it! --Frank Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Bertoni, Colleen <bertoni(a)anl.gov> Sent: Thursday, March 18, 2021 4:47 PM To: Applencourt, Thomas <tapplencourt(a)anl.gov>; ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov>; Willmore, Frank Ted <willmore(a)anl.gov> Subject: Re: unfortunately named fortran compiler option -loopopt=0 Hi Frank, Yeah, I remember this discussion for Fortran before (https://community.intel.com/t5/Intel-Fortran-Compiler/ifx-2021-1-beta04-HPC…) This looks like C, though. Is it possible for you to send steps to reproduce? Thanks, Colleen ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Thursday, March 18, 2021 1:00 PM To: Applencourt, Thomas <tapplencourt(a)anl.gov>; ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov>; Willmore, Frank Ted <willmore(a)anl.gov> Subject: Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Hi-- I'm running into this same issue again. HDF5 will not configure because compilation is misinterpreting a flag: /soft/restricted/CNDA/mpich/drop39.1/mpich-ofi-sockets-icc-debug-gen9-drop39/bin/mpicc -o conftest -fPIC conftes t.c -loopopt=0 ... The culprit here is -loopopt, which is intended, presumably, for the compiler, but which is being passed to the linker which thinks it should link libloopopt (which isn't a thing). I had previously been able to work around this by using ifort instead of ifx, but ifort is no longer part of the distribution. Also, I can no longer view the discussion on the intel site at https://software.intel.com/en-us/comment/1952923# * Has there been any activity on this issue? * Is this an issue that HDF5 and the other packages who include this option need to deal with individually in their build systems? * What is the intent of this option, will it continue to exist, and is there an alternative? Thanks, --Frank Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Tuesday, September 29, 2020 4:31 PM To: Applencourt, Thomas <tapplencourt(a)anl.gov>; ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Subject: Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Thank you for replying, Thomas and Brian. I tried adding the --best-effort flag, but ifx didn't understand it. Realizing there's an ifort executable available from the oneapi module, I pointed to that and was able to configure and build hypre with that. I'm driving this from spack, and am including the compiler stanza I used below, if anyone is interested. I hacked up my own version of the oneapi module which points to pure opensuse builds of gcc, etc. since spack refuses to cross-compile to a different OS. It's an ugly hack, but I can share if anyone is interested. - compiler: spec: intel(a)2020.09.15.001 paths: cc: icx cxx: icpx f77: ifort fc: ifort operating_system: opensuse_leap15 target: x86_64 modules: - /home/willmore/modulefiles/intel-oneapi/hacked environment: prepend_path: LD_LIBRARY_PATH: /home/willmore/lib:/soft/restricted/CNDA/sdk/2020.7.30.1/oneapi/compiler/2021.1-beta08/linux/compiler/lib/intel64_lin unset: [] extra_rpaths: [] Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Applencourt, Thomas <tapplencourt(a)anl.gov> Sent: Tuesday, September 29, 2020 2:15 PM To: ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov>; Willmore, Frank Ted <willmore(a)anl.gov> Subject: Re: unfortunately named fortran compiler option -loopopt=0 Hi Frank, >Would falling back to an older ifort version to build Fortran components be a reasonable option? This is not an `official remand way` just a workaround we implemented, but you can try to add `--best-effort` flags with `ifx`. It will fall back to `ifort` if something goes wrong. So maybe it can help you when waiting for an official fix. Thomas Applencourt Leadership Computing Facility Argonne National Laboratory Building 240 Office - 1.D.18 9700 S Cass Av., Lemont Il, 60439 (630) 252-0036 ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Tuesday, September 29, 2020 14:04 To: ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Subject: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Hi-- I've been bumping against a known issue with ifx, namely that ifx generates a flag "-loopopt=0" which is intended to be consumed by an internal component (xfortcom) but which causes ld to erroneously try to link liboopopt=0 instead, and thus causing configure to fail. I'm attempting to build hypre. More on the issue here: https://software.intel.com/en-us/comment/1952923# When I configure, I get (among other things): /usr/bin/ld: cannot find -loopopt=0 error: linking to Fortran libraries from C fails Has anyone else here stumbled on this when compiling Fortran, and if so, how did you work around it? Would falling back to an older ifort version to build Fortran components be a reasonable option? Thanks, --Frank Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]>

1 0

Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0
by Bertoni, Colleen 18 Mar '21

18 Mar '21

Hi Frank, Yeah, I remember this discussion for Fortran before (https://community.intel.com/t5/Intel-Fortran-Compiler/ifx-2021-1-beta04-HPC…) This looks like C, though. Is it possible for you to send steps to reproduce? Thanks, Colleen ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Thursday, March 18, 2021 1:00 PM To: Applencourt, Thomas <tapplencourt(a)anl.gov>; ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov>; Willmore, Frank Ted <willmore(a)anl.gov> Subject: Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Hi-- I'm running into this same issue again. HDF5 will not configure because compilation is misinterpreting a flag: /soft/restricted/CNDA/mpich/drop39.1/mpich-ofi-sockets-icc-debug-gen9-drop39/bin/mpicc -o conftest -fPIC conftes t.c -loopopt=0 ... The culprit here is -loopopt, which is intended, presumably, for the compiler, but which is being passed to the linker which thinks it should link libloopopt (which isn't a thing). I had previously been able to work around this by using ifort instead of ifx, but ifort is no longer part of the distribution. Also, I can no longer view the discussion on the intel site at https://software.intel.com/en-us/comment/1952923# * Has there been any activity on this issue? * Is this an issue that HDF5 and the other packages who include this option need to deal with individually in their build systems? * What is the intent of this option, will it continue to exist, and is there an alternative? Thanks, --Frank Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Tuesday, September 29, 2020 4:31 PM To: Applencourt, Thomas <tapplencourt(a)anl.gov>; ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Subject: Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Thank you for replying, Thomas and Brian. I tried adding the --best-effort flag, but ifx didn't understand it. Realizing there's an ifort executable available from the oneapi module, I pointed to that and was able to configure and build hypre with that. I'm driving this from spack, and am including the compiler stanza I used below, if anyone is interested. I hacked up my own version of the oneapi module which points to pure opensuse builds of gcc, etc. since spack refuses to cross-compile to a different OS. It's an ugly hack, but I can share if anyone is interested. - compiler: spec: intel(a)2020.09.15.001 paths: cc: icx cxx: icpx f77: ifort fc: ifort operating_system: opensuse_leap15 target: x86_64 modules: - /home/willmore/modulefiles/intel-oneapi/hacked environment: prepend_path: LD_LIBRARY_PATH: /home/willmore/lib:/soft/restricted/CNDA/sdk/2020.7.30.1/oneapi/compiler/2021.1-beta08/linux/compiler/lib/intel64_lin unset: [] extra_rpaths: [] Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Applencourt, Thomas <tapplencourt(a)anl.gov> Sent: Tuesday, September 29, 2020 2:15 PM To: ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov>; Willmore, Frank Ted <willmore(a)anl.gov> Subject: Re: unfortunately named fortran compiler option -loopopt=0 Hi Frank, >Would falling back to an older ifort version to build Fortran components be a reasonable option? This is not an `official remand way` just a workaround we implemented, but you can try to add `--best-effort` flags with `ifx`. It will fall back to `ifort` if something goes wrong. So maybe it can help you when waiting for an official fix. Thomas Applencourt Leadership Computing Facility Argonne National Laboratory Building 240 Office - 1.D.18 9700 S Cass Av., Lemont Il, 60439 (630) 252-0036 ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Tuesday, September 29, 2020 14:04 To: ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Subject: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Hi-- I've been bumping against a known issue with ifx, namely that ifx generates a flag "-loopopt=0" which is intended to be consumed by an internal component (xfortcom) but which causes ld to erroneously try to link liboopopt=0 instead, and thus causing configure to fail. I'm attempting to build hypre. More on the issue here: https://software.intel.com/en-us/comment/1952923# When I configure, I get (among other things): /usr/bin/ld: cannot find -loopopt=0 error: linking to Fortran libraries from C fails Has anyone else here stumbled on this when compiling Fortran, and if so, how did you work around it? Would falling back to an older ifort version to build Fortran components be a reasonable option? Thanks, --Frank Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]>

1 0

Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0
by Willmore, Frank Ted 18 Mar '21

18 Mar '21

Hi-- I'm running into this same issue again. HDF5 will not configure because compilation is misinterpreting a flag: /soft/restricted/CNDA/mpich/drop39.1/mpich-ofi-sockets-icc-debug-gen9-drop39/bin/mpicc -o conftest -fPIC conftes t.c -loopopt=0 ... The culprit here is -loopopt, which is intended, presumably, for the compiler, but which is being passed to the linker which thinks it should link libloopopt (which isn't a thing). I had previously been able to work around this by using ifort instead of ifx, but ifort is no longer part of the distribution. Also, I can no longer view the discussion on the intel site at https://software.intel.com/en-us/comment/1952923# * Has there been any activity on this issue? * Is this an issue that HDF5 and the other packages who include this option need to deal with individually in their build systems? * What is the intent of this option, will it continue to exist, and is there an alternative? Thanks, --Frank Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Tuesday, September 29, 2020 4:31 PM To: Applencourt, Thomas <tapplencourt(a)anl.gov>; ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Subject: Re: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Thank you for replying, Thomas and Brian. I tried adding the --best-effort flag, but ifx didn't understand it. Realizing there's an ifort executable available from the oneapi module, I pointed to that and was able to configure and build hypre with that. I'm driving this from spack, and am including the compiler stanza I used below, if anyone is interested. I hacked up my own version of the oneapi module which points to pure opensuse builds of gcc, etc. since spack refuses to cross-compile to a different OS. It's an ugly hack, but I can share if anyone is interested. - compiler: spec: intel(a)2020.09.15.001 paths: cc: icx cxx: icpx f77: ifort fc: ifort operating_system: opensuse_leap15 target: x86_64 modules: - /home/willmore/modulefiles/intel-oneapi/hacked environment: prepend_path: LD_LIBRARY_PATH: /home/willmore/lib:/soft/restricted/CNDA/sdk/2020.7.30.1/oneapi/compiler/2021.1-beta08/linux/compiler/lib/intel64_lin unset: [] extra_rpaths: [] Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Applencourt, Thomas <tapplencourt(a)anl.gov> Sent: Tuesday, September 29, 2020 2:15 PM To: ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov>; Willmore, Frank Ted <willmore(a)anl.gov> Subject: Re: unfortunately named fortran compiler option -loopopt=0 Hi Frank, >Would falling back to an older ifort version to build Fortran components be a reasonable option? This is not an `official remand way` just a workaround we implemented, but you can try to add `--best-effort` flags with `ifx`. It will fall back to `ifort` if something goes wrong. So maybe it can help you when waiting for an official fix. Thomas Applencourt Leadership Computing Facility Argonne National Laboratory Building 240 Office - 1.D.18 9700 S Cass Av., Lemont Il, 60439 (630) 252-0036 ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Willmore, Frank Ted via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Tuesday, September 29, 2020 14:04 To: ECP Aurora <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Subject: [Ecp-aurora-sdk-discuss] unfortunately named fortran compiler option -loopopt=0 Hi-- I've been bumping against a known issue with ifx, namely that ifx generates a flag "-loopopt=0" which is intended to be consumed by an internal component (xfortcom) but which causes ld to erroneously try to link liboopopt=0 instead, and thus causing configure to fail. I'm attempting to build hypre. More on the issue here: https://software.intel.com/en-us/comment/1952923# When I configure, I get (among other things): /usr/bin/ld: cannot find -loopopt=0 error: linking to Fortran libraries from C fails Has anyone else here stumbled on this when compiling Fortran, and if so, how did you work around it? Would falling back to an older ifort version to build Fortran components be a reasonable option? Thanks, --Frank Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]>

1 0