Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1558: trying to activate more thorns than compiled into Cactus leads to strange error message
by Einstein Toolkit 19 Apr '14

19 Apr '14

#1558: trying to activate more thorns than compiled into Cactus leads to strange error message --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- Right now if one tries to activate more thorns than the total number of thorns compiled into the executable, Cactus aborts with {{{ WARNING level 0 in thorn Cactus processor 0 host horizon.tapir.caltech.edu (line 951 of /mnt/data/rhaas/postdoc/gr/Zelmani/configs/null/build/Cactus/main/ActiveThorns.c): -> Internal error }}} this is utimately due to Cactus creating a list of maximum size number-of- compiled-in-thorns to record the number of thorns that are requested to be activated. The attached patches automatically grows this list whenever it would otherwise be too small (doubles the size). An alternative would be to implement stringlist using a std::map object, however the mapping of the std::map interface to what StringList provides is cumbersome. ok to apply? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1558> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[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

[Einstein Toolkit] #1536: Wrong code in Piraha.hpp
by Einstein Toolkit 27 Mar '14

27 Mar '14

#1536: Wrong code in Piraha.hpp ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- Piraha.hpp contains in lines 171 ff the code {{{ const char c; Literal(char b) : c(b) {} bool match(Matcher *m); std::string fmt() { std::string s = "literal("; s += c+")"; return s; } }}} In this code, the expression c+")" adds a character to a pointer, in effect adding to the pointer. This does not append to the string s, as was intended. There seem to be several similar cases in other locations as well. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1536> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1568: Reduce overhead of Formaline
by Einstein Toolkit 26 Mar '14

26 Mar '14

#1568: Reduce overhead of Formaline -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- The Formaline thorn, used for storing important information about a simulation in the simulation output, currently has some performance and size overheads which discourage people from using it. These should be reduced or mitigated to encourage people to use this important thorn. This ticket is based on discussion in #1565. Problems with Formaline: * During compilation, Formaline stores the built source tree in a cactusjar.git repository. My impression is that this takes a lot of time on slow filesystems. * During compilation, Formaline stores the whole source tree as tarballs in the executable. My impression is that this is also slow. * The source tarballs output in the simulation output directory are often many times larger than the rest of the simulation, and cause a lot of overhead when transferring simulations for analysis. This might be improved by a better sync tool (simfactory 3?) which identified that tarballs were identical to those which have already been transferred, and skipped the transfer. I would like that the source tarballs are identical if the contents are identical, even if Cactus has been rebuilt. I think I observed that this was not the case (maybe a build ID is included?). * As an aside: there is a message at link time that Formaline has finished doing something, but this is misleading; Formaline has other tasks which it does after this message is displayed; the wait for the final executable is not due solely to linking, but also to some archiving task of formaline. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1568> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac