Trac April 2014

trac@lists.einsteintoolkit.org

1 participants
157 discussions

[Einstein Toolkit] #1571: incorrect use of CCTK_BUILTIN_UNREACHABLE in Carpet
by Einstein Toolkit 19 Apr '14

19 Apr '14

#1571: incorrect use of CCTK_BUILTIN_UNREACHABLE in Carpet --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- Carpet in commit fc35c561a049d905763de37d60690fc15473d65d "CarpetLib: Some harmless code cleanup" (sic) replaced some assert(0) by CCTK_BUILTIN_UNREACHABLE(). One of those (in the switch in transfer_p_r in line 730 of data.cc) was just found by Zach Etienne to cause segfaults if one does not properly add a new interpolation operator. The difference is that CCTK_BUILTIN_UNREACHABLE() tells the compiler that a given line of code will never be reached thus the compiler can optimize it away. assert(0) on the other hand makes no such statement, it just aborts if it is reached. This error is compiler dependent since CCTK_BUILTIN_UNREACHABLE() expands to CCTK_Abort(0,1) unless the compiler supports __builtin_unreachable. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1571> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #849: Drop explicit support for Fortran 77 in Cactus
by Einstein Toolkit 19 Apr '14

19 Apr '14

#849: Drop explicit support for Fortran 77 in Cactus -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- I suggest to drop explicit support for Fortran 77 in Cactus. Fortran 77 is, for all practical purposes, a subset of Fortran 90, and thus Fortran 77 code can be compiled by Fortran 90 compilers. There is currently no platform that has a Fortran 77 and no Fortran 90 compiler, and there is no Fortran source code in Cactus that cannot be compiled by a Fortran 90 compiler. In a way, supporting Fortran 77 as language is similar to supporting K&R C as a language. We don't do this either. I suggest to remove/ignore all configuration options regarding Fortran 77, and to compile .f77 and .F77 files with a Fortran 90 compiler. This change will simplify the configuration stage of Cactus. I don't expect any user to notice. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/849> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1563: Provide always-working isnan etc.
by Einstein Toolkit 19 Apr '14

19 Apr '14

#1563: Provide always-working isnan etc. -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Certain math optimization options (e.g. -ffast-math) tell the compiler that IEEE floating point numbers such as inf and nan do not need to be handled correctly (in the sense specified by the IEEE standard). This greatly improves floating-point speed and is commonly used in numerical HPC applications. For example, fmax() specifies: {{{ If exactly one argument is a NaN, fmax() returns the other argument. If both arguments are NaNs, fmax() returns a NaN. }}} Implementing this correctly requires checking whether each argument is a nan. To improve speed, one can omit this check, which means that fmax() may return NaN, even if one of its argument is not a NaN. This is fine in most cases, and people appreciate the added speed. However, since compilers then don't need to handle inf and nan correctly, they have begun to optimise isnan(x) to simply returning false all the time. This improves speed (since the check does not actually need to occur) and reduces code size (since the nan-handling if branches can be omitted). Of course, this makes it then impossible to actually check for nan by calling isnan. Currently, e.g. g++ performs this optimisation, whereas gcc does not. Things vary with other compilers. In the future, with link-time optimisations, I expect other compilers to follow g++. The enclosed patch provides functions CCTK_IEEE_isnan etc. that always check for nan, independent of the chosen optimisation flags. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1563> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1567: Lorene: compilation error when using -warn all
by Einstein Toolkit 18 Apr '14

18 Apr '14

#1567: Lorene: compilation error when using -warn all --------------------------------------+------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2014_05 Component: EinsteinToolkit thorn | Version: ET_2013_11 Keywords: Lorene ExternalLibraries | --------------------------------------+------------------------------------- If I add the warning flag to fortran flags in my configuration option list, i.e.: F77_WARN_FLAGS = -warn all F90_WARN_FLAGS = -warn all Lorene's compilation abort with the following error messages: ... fcir2s.f(216): error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [NDEG1] CALL CIRX2S(NDEG1,NDIMR,NN64,ITCH,IDR,IND,C64,CC,CS,DENT) -------------------^ fcir2s.f(240): error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [NDEG1] CALL CIRX2S(NDEG1,NDIMR,NN64,ITCH,IDR,IND,C64,CC,CS,DENT) -------------------^ ... gr2p3s.f(719): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic. [SOM] CALL EXRM1S(NR,NDR,1,1,0,IPP,CC,VA1) -------------^ gr2p3s.f(720): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic. [SOM] CALL EXRM1S(NR,NDR,1,1,1,IPP,CC,DE1) -------------^ The first compilation error above indicates that NDEG1 is an array with dimension 2 in the calling subroutine FCIR2S while NDEG has dimension 3 in the called subroutine CIRX2S. A suggestion to work around this issue can be found at: http://software.intel.com/en-us/forums/topic/299025 and it boils down to make them both of the same dimension. Would you suggest a different workaround? Maybe make the dummy array dimension a (*)? Regarding the second type of error above, I am not sure yet which argument is actually causing trouble. My local version of Lorene indicates different line number than the error line above but essentially the difference between the calls that the compiler complaints and the ones it doesn't is the following: grep -i -n EXRM1S gr2p3s.f gr2p3s.f:694: CALL EXRM1S(NR,NDR,LF1,1,0,IPP,CC,C64) gr2p3s.f:695: CALL EXRM1S(NR,NDR,LF1,1,1,IPP,CC,UGRAV) gr2p3s.f:718: CALL EXRM1S(NR,NDR,1,1,0,IPP,CC,VA1) gr2p3s.f:719: CALL EXRM1S(NR,NDR,1,1,1,IPP,CC,DE1) On lines 694 and 695 there is no complaint from the compiler. While lines 718 and 719 do. So the dummy argument LF1 seems to prevent this compilation error in an earlier call. In any case, do you have any idea on how to fix this? Note that a workaround I found was to disable the compiler check for the subroutine interfaces by adding the following flag: F77_WARN_FLAGS = -warn all -warn nointerfaces F90_WARN_FLAGS = -warn all -warn nointerfaces However I would rather have this issue addressed than let it go silently. Besides it might affect other fortran codes in ET which I haven't had the opportunity to investigate yet. I have posted a message on Lorene mailing list about this issue. If I don't hear from them, maybe we should come up with a patch on our own. Could someone more familiar with Lorene inner workings come up with a suggestion for this patch? I could work on it and test it. Thanks, Bruno. PS: I found this article useful: http://software.intel.com/en-us/blogs/2009/03/31/doctor-fortran-in-ive- come-here-for-an-argument -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1567> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1570: QuasiLocalMeasures qlm_killing_normalise.F90 contains commented out code with no comment
by Einstein Toolkit 17 Apr '14

17 Apr '14

#1570: QuasiLocalMeasures qlm_killing_normalise.F90 contains commented out code with no comment -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: QuasiLocalMeasures | -----------------------------------+---------------------------------------- qlm_killing_normalise in qlm_killing_normalise.F90 triggers an unused variable warning for iii. Looking at the file, the code that would use the variable is inside of an {{{#if 0}}} but there is no indication (neither in the commit message nor in the code) what the difference between the if and the else branch is. I'd like to either replace the if0 by an if USE_THIS_MEHTOD (and use the same preprocessor constant for the variable declaration) or (even better) remove the whole if0 branch. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1570> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1531: GRHydro updates
by Einstein Toolkit 15 Apr '14

15 Apr '14

#1531: GRHydro updates -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: GRHydro EOS_Omni | -----------------------------------+---------------------------------------- A large number of GRHydro updates have accumulated. Attached please find them all as well as a required update to EOS_Omni. Patches to follow in a bit. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1531> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1572: add Cray abnormal-termination-processing modules to bluewaters
by Einstein Toolkit 14 Apr '14

14 Apr '14

#1572: add Cray abnormal-termination-processing modules to bluewaters -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: bluewaters | -------------------------+-------------------------------------------------- bluewaters offers these modules to be used when compiling and running https://bluewaters.ncsa.illinois.edu/atp so that failing runs actually write a core dump and provide backtrace on stderr. I used them to debug a SEGFAULT in code I had not written myself (which are the hard ones sine one has no idea where the segfault might be coming from). With the core dump (since bluewaters uses the gnu compiler) the issue was resolved within minutes. Are there any known issues with including the modules? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1572> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac April 2014