Hi,
I've encountered various issues from recent Intel compilers. Except for some versions having header file issues, I could manage to build ET executables but actual run stalled at various steps depending on the compiler versions. For example,
Case 1. Before initial data generation ... INFO (CarpetRegrid2): Enforcing grid structure properties, iteration 1 INFO (CarpetRegrid2): Enforcing grid structure properties, iteration 0 INFO (CarpetRegrid2): Enforcing grid structure properties, iteration 1
Case 2. During reading Lorene data (e.g., while reading resu.d)
Case 3. Evolution started with normal IDs but NaNs produced from the next evolution step.
I've encountered the issues in various combinations of OneAPI/IntelMPI and OneAPI/OpenMPI on Centos8 (gcc-8.3.1) machines.
There had been no issues for OpenMPI/GCC. But I've just found Case 1 is produced on an old machine with devtoolset gcc-6.3.1/openmpi-1.8.4.
You have any hints for the issue? Thanks in advance.
Hee Il
Can you specify the compiler versions (1) that work, (2) that don't work and (3) the par file you are trying to run? Thanks.
--Steve
On 8/7/2021 4:20 AM, Hee Il Kim wrote:
Hi,
I've encountered various issues from recent Intel compilers. Except for some versions having header file issues, I could manage to build ET executables but actual run stalled at various steps depending on the compiler versions. For example,
Case 1. Before initial data generation ... INFO (CarpetRegrid2): Enforcing grid structure properties, iteration 1 INFO (CarpetRegrid2): Enforcing grid structure properties, iteration 0 INFO (CarpetRegrid2): Enforcing grid structure properties, iteration 1
Case 2. During reading Lorene data (e.g., while reading resu.d)
Case 3. Evolution started with normal IDs but NaNs produced from the next evolution step.
I've encountered the issues in various combinations of OneAPI/IntelMPI and OneAPI/OpenMPI on Centos8 (gcc-8.3.1) machines.
There had been no issues for OpenMPI/GCC. But I've just found Case 1 is produced on an old machine with devtoolset gcc-6.3.1/openmpi-1.8.4.
You have any hints for the issue? Thanks in advance.
Hee Il
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hi Steve,
I'm replying to my original post. You can reproduce the crash with NaNs by using the gallery parfile (nsnstohmns.par) and the id of binary neutron star mergers.
The version of OneAPI is: /opt/intel/oneapi/mpi/2021.3.0/bin/mpicc
The command used is: $ mpiexec.hydra -env OMP_NUM_THREADS 1 -n 48 ./SIMFACTORY/cactus_bns_1api -L 3 nsnstohmns.par
Other than the Nan production, the remaining issues seem to be fixed somehow by tweaking runtime options. If you have any working runtime configurations, please let me know.
You can find more (minor?) Intel compiler issues below. But please note the failure of Intel-2020.
Thanks,
Hee Il
On Sat, Aug 7, 2021 at 6:20 PM Hee Il Kim heeilkim@gmail.com wrote:
Hi,
I've encountered various issues from recent Intel compilers. Except for some versions having header file issues, I could manage to build ET executables but actual run stalled at various steps depending on the compiler versions. For example,
Case 1. Before initial data generation ... INFO (CarpetRegrid2): Enforcing grid structure properties, iteration 1 INFO (CarpetRegrid2): Enforcing grid structure properties, iteration 0 INFO (CarpetRegrid2): Enforcing grid structure properties, iteration 1
I couldn't recall when this happened. But as mentioned below, it might be fixed by taking proper runtime options.
Case 2. During reading Lorene data (e.g., while reading resu.d)
Seemingly, this is also related to the runtime environment. Broken load-balancing at some point makes the calculation extremely slow.
Case 3. Evolution started with normal IDs but NaNs produced from the next
evolution step.
I've encountered the issues in various combinations of OneAPI/IntelMPI and OneAPI/OpenMPI on Centos8 (gcc-8.3.1) machines.
This is the main issue.
There had been no issues for OpenMPI/GCC. But I've just found Case 1 is produced on an old machine with devtoolset gcc-6.3.1/openmpi-1.8.4.
Please forget about this. There were some conflicts between shared memory options (sm, vader, kmem etc), which were fixed by taking proper runtime options.
I didn't make a lot of effort because the machine was small and temporarily accessible, but here's the additional note for the other Intel versions:
- intel 2020 update 2 cluster edition. - & intel 2019u0 and 2019u5 runtime error due to CarpetRegrid2: NaNs are produced because of wrong grid setup. ... ERROR from host xeon2.localdomain.com process 5 in thorn CarpetRegrid2, file /home/khi/ET/Turing/arrangements/Carpet/CarpetRegrid2/src/regrid.cc:91: -> Region 3 has 8 levels active, which is larger than the maximum number of refinement levels 6
- Intel 2018u1 failed to find c++11 compilers. -std=gnu++11, c++11 both failed even for hello.c
- Intel 2017u2 & 2017u8 checking for M_PI... no configure: error: M_PI not defined. Try adding -D_XOPEN_SOURCE to CPPFLAGS.
Hi,
As James Healy mentioned in the post "[Users] Einstein Toolkit and modern AMD supercomputer", I found static_tov.par passed the test for the Intel issue. So some bns-generic codes would make NaNs. But less probable because the only bns-generic code would be NSTracker but I've already encountered the NaN production issue w/wo NSTracker.
NaNChecker itself could be suspected but both bns and tove tests are using NaNChecker.
Rather, it could be a generic issue of Intel compiler. There are some bugs reported and new features in handling NaNs for the case of ifx. Those look just irrelevant yet.
Hee Il
Sorry I lost track of this email thread. I got caught up with other things. I'm wondering whether you have tried compiling with fp-precise? I'm just wondering whether it could be a problem with Intel's optimization.
--Steve
On 9/1/2021 6:21 AM, Hee Il Kim wrote:
Hi,
As James Healy mentioned in the post "[Users] Einstein Toolkit and modern AMD supercomputer", I found static_tov.par passed the test for the Intel issue. So some bns-generic codes would make NaNs. But less probable because the only bns-generic code would be NSTracker but I've already encountered the NaN production issue w/wo NSTracker.
NaNChecker itself could be suspected but both bns and tove tests are using NaNChecker.
Rather, it could be a generic issue of Intel compiler. There are some bugs reported and new features in handling NaNs for the case of ifx. Those look just irrelevant yet.
Hee Il
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
users@lists.einsteintoolkit.org