- removed comment
Catastrophic test failures with Intel 11
Issue #1480
closed
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.
Keyword:
Comments (7)
-
-
- changed status to open
- removed comment
-
- changed status to open
- removed 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++.
-
- changed status to resolved
- removed 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.
-
- removed comment
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.
-
reporter
- removed comment
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.
-
- edited description
- changed status to closed
- Log in to comment
- Assignee
- –
- Type
- Priority
- Status
- closed
- Component
- EinsteinToolkit thorn
- Milestone
- ET_2013_11
- Version
- development version
- Votes
- 0
- Watchers
- 0
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?