Here is what @chuckatkins wrote to me when I forwarded him your earlier withdrawn post for help:
I believe I know what the issue is but it seems the author has deleted the topic. So, in case it comes up again, here’s what I believe the issue is:
module load craype-haswell
…
Cmake file for configuring:
paraview-cray-serc.cmake
…
gmake[3]: *** [Include/graminit.h] Illegal instruction
gmake[3]: *** Waiting for unfinished jobs…
If I’m inferring the situation correctly, this is on the SahasraT machine at SERC in India. If that’s the case, then on this machine you have 4 different user accessible node architectures (not counting the DVS nodes):
- Service (login): Sandy Bridge CPUs
- Compute CPU: Haswell CPUs
- Compute GPU: IvyBridge CPUs and NVidia GPUs
- Compute Phi: Ivy Bridge CPUs and Xeon Phi accelerator cards
By loading the craype-haswell module then I assume this build is intended to target the CPU compute nodes. However, if the user is building from one of the service nodes like a login / compute node then it’s actually a cross compiling scenario, which the superbuild inherently does not work for since code is being compiled for Haswell CPUs but some of the intermediate build products need to be run during the build on the local SandyBridge CPU, which results in the “illegal instruction”. The two options are to either build on a compute node so it’s no longer a cross compiling scenario or, the approach I recommend is to continue to build on the login node but use the craype-sandybridge target which is forward compatible with the haswell CPUs on the compute nodes. The only performance critical area that this would affect is rendering, in which case the performance is the result of llvm, swr, and ospray. LLVM will already adapt it’s code generation to the underlying CPU it’s running on and ospray is already configured by default to support all available architectures with different runtime backends. So the only configuration change is really to ensure that swr is built to support both CPU.
So, in summary, the user should make the following adjustments:
- Use the craype-sandybridge module instead of craype-haswell
- Add the following two entries to their paraview-cray-serc.cmake cache file:
- set(mesa_SWR_ARCH “avx,avx2” CACHE STRING “”)