#1480: Catastrophic test failures with Intel 11 -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: blocker | Milestone: ET_2013_11 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- Several tests fail with very large differences or NaNs with Intel 11, but not with later versions of the compiler. We suspect this is due to a buggy implementation of Cray pointers, newly used in GRHydro since the last release. The affected tests are:
{{{ GRHydro_test_shock_mp5 (from GRHydro) GRHydro_test_shock_ppm (from GRHydro) GRHydro_test_shock_weno (from GRHydro) tov_slowsector (from GRHydro) diag_flip_pugh_eno (from Hydro_InitExcision) diag_pugh_eno (from Hydro_InitExcision) halfsphere_pugh_ppm (from Hydro_InitExcision) sphere_pugh_ppm (from Hydro_InitExcision) x_flip_pugh_eno (from Hydro_InitExcision) x_pugh_eno (from Hydro_InitExcision) }}}
Roland is going to try to implement a workaround for the compiler bug.
#1480: Catastrophic test failures with Intel 11 ------------------------------------+--------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: blocker | Milestone: ET_2013_11 Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by rhaas):
It turns out to be quite difficult to come up with a way that compiles (quickly) and runs (correcly, quickly) with intel 11, 12, 13 and gfortran (the later never being a problem) .
I have now tried: * Fortran 90 pointers * Cray pointers * nested subroutines * CCTK_PASS_FTOF * explicit if statements in inner loops
It turns out that only "explicit if statements in inner loops" lets me compile the Reconstruction driver routines (which is where the catastrophy happened) compile with intel 13 and also intel 11.
The attached patch replaces the use of Fortran pointers in the reconstruction drivers for PPM, PPM-MHD, WENO, MP5, ENO with explicit if statements in the second (of three nested) loops. For some reason that I do not understand the compiler does not die compiling TVDReconstruct with the (much nicer) construct using nested subroutines.
The code compiles and runs using intel 11 and 12 (zwicky) as well as intel 13 (stampede, bethe) and gfortran 4.8 (my workstation).
Ok to apply?
#1480: Catastrophic test failures with Intel 11 ------------------------------------+--------------------------------------- Reporter: hinder | Owner: Type: defect | Status: review Priority: blocker | Milestone: ET_2013_11 Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+--------------------------------------- Changes (by rhaas):
* status: new => review
#1480: Catastrophic test failures with Intel 11 ------------------------------------+--------------------------------------- Reporter: hinder | Owner: Type: defect | Status: reviewed_ok Priority: blocker | Milestone: ET_2013_11 Component: EinsteinToolkit thorn | Version: development version Resolution: | Keywords: ------------------------------------+--------------------------------------- Changes (by eschnett):
* status: review => reviewed_ok
Comment:
These changes are straightforward, and address a catastrophic failure. They are thus okay to apply.
In the long term we need to address this design. Given that this complexity is mostly caused by deficiencies of the language Fortran, I am tempted to recommend rewriting such routines in C++.
#1480: Catastrophic test failures with Intel 11 ------------------------------------+--------------------------------------- Reporter: hinder | Owner: Type: defect | Status: closed Priority: blocker | Milestone: ET_2013_11 Component: EinsteinToolkit thorn | Version: development version Resolution: fixed | Keywords: ------------------------------------+--------------------------------------- Changes (by rhaas):
* status: reviewed_ok => closed * resolution: => fixed
Comment:
There are plans to rewrite GRHydro using C++, yes. Some of this has already started in the PPM routines. Christian R, Philipp and I had plans to have a coding weekend at one point at get started with this.
Applied as GRHydro rev 587.
#1480: Catastrophic test failures with Intel 11 ------------------------------------+--------------------------------------- Reporter: hinder | Owner: Type: defect | Status: closed Priority: blocker | Milestone: ET_2013_11 Component: EinsteinToolkit thorn | Version: development version Resolution: fixed | Keywords: ------------------------------------+---------------------------------------
Comment (by knarf):
Also something to keep in mind is that Intel 11 is getting old. I just found out that the two main machines at LSU that still use it (queenbee and tezpur) are very likely to be decommissioned within the next year, and replaced by something newer. Intel 11 isn't there to stay.
#1480: Catastrophic test failures with Intel 11 ------------------------------------+--------------------------------------- Reporter: hinder | Owner: Type: defect | Status: closed Priority: blocker | Milestone: ET_2013_11 Component: EinsteinToolkit thorn | Version: development version Resolution: fixed | Keywords: ------------------------------------+---------------------------------------
Comment (by hinder):
I think we should try to update compiler versions more than we do. I read somewhere that Intel support the current and previous version of the compiler; that would be versions 14 and 13 now. We should probably not use unsupported compilers if possible. After the release, we should change simfactory optionlists to use newer compilers where these are available. I will do so on Datura.
trac@lists.einsteintoolkit.org
-
Einstein Toolkit