Trac June 2013

trac@lists.einsteintoolkit.org

1 participants
163 discussions

[Einstein Toolkit] #456: Ensure functions are not defined twice
by Einstein Toolkit 08 Jul '13

08 Jul '13

#456: Ensure functions are not defined twice -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- When multiple source files define non-static functions with the same name, these are all compiled together into the resulting executable. Which one gets called is not predictable by the user. This can happen if a user copies a thorn, modifies it slightly, and compiles both thorns into the same configuration. This can lead to *very* difficult-to-find bugs, and it would be helpful if Cactus was able to prevent this, or at least to mitigate the problem. At the CST level, Cactus should be able to tell that there are two thorns which schedule functions with the same name. At the moment, this is not caught. I propose that this should be a fatal error, as there is no way to predict which function will be called eventually. This will solve the problem in some cases, but not in the case where there are instances of duplicate function names which are not scheduled. It should be possible to scan the object/library files using standard tools (nm etc) to determine if there are multiple globally visible symbols with the same name. There might even be standard tools for this purpose. Doing this in a portable way might not be straightforward, but having an implementation for Linux, for example, would catch the majority of cases. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/456> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1348: simfactory doesn't support multi-core setup using setup-silent
by Einstein Toolkit 07 Jul '13

07 Jul '13

#1348: simfactory doesn't support multi-core setup using setup-silent -------------------------+-------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- It is easy to see why a complete multi-core setup using setup-silent isn't the best way to go. Editing the resulting file is usually so much more convenient. However, the attached patch adds the possibility to have the options --ppn and --num-threads being taken into account for setup-silent. --ppn sets 'ppn', 'max-num-threads' to it's value, and 'make' to 'nice make -j'+value. --num-threads sets 'num-threads'. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1348> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1379: Rename autoconfigured CCTK_BUILTIN functions to __builtin
by Einstein Toolkit 07 Jul '13

07 Jul '13

#1379: Rename autoconfigured CCTK_BUILTIN functions to __builtin -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- With autoconf, it is common to define a work-around if a tested feature does not exist. For example, when the "inline" keyword does not exist, then there is a #define that allows code to still use "inline", instead of requiring all code to use CCTK_INLINE. This keeps code more readable. Cactus tests for various __builtin_* features (__builtin_expect, __builtin_unreachable). If these are not present, it defines CCTK_BUILTIN work-around that one can use instead. I suggest to provide instead the respective __builtin_* functions. We would keep the current CCTK_BUILTIN_* variants for backward compatibility (at least for some time), but would not define them for new builtins that we autoconfigure. $ svn diff cctk_Config.h.in Index: cctk_Config.h.in =================================================================== --- cctk_Config.h.in (revision 5021) +++ cctk_Config.h.in (working copy) @@ -376,6 +376,7 @@ # define CCTK_BUILTIN_EXPECT(x,y) __builtin_expect(x,y) #else # define CCTK_BUILTIN_EXPECT(x,y) (x) +# define __builtin_expect(x,y) CCTK_BUILTIN_EXPECT(x,y) #endif /* Whether __builtin_unreachable exists. */ @@ -384,8 +385,15 @@ # define CCTK_BUILTIN_UNREACHABLE() __builtin_unreachable() #else # define CCTK_BUILTIN_UNREACHABLE() CCTK_Abort(0, 1) +# define __builtin_unreachable() CCTK_BUILTIN_UNREACHABLE() #endif /* OpenMP collapse clause */ #if (defined CCTK_DISABLE_OMP_COLLAPSE || \ (defined __IBMC__ && defined _ARCH_450D) || \ @@ -585,6 +593,7 @@ # define CCTK_BUILTIN_EXPECT(x,y) __builtin_expect(x,y) #else # define CCTK_BUILTIN_EXPECT(x,y) (x) +# define __builtin_expect(x,y) CCTK_BUILTIN_EXPECT(x,y) #endif /* Whether __builtin_unreachable exists. */ @@ -593,8 +602,15 @@ # define CCTK_BUILTIN_UNREACHABLE() __builtin_unreachable() #else # define CCTK_BUILTIN_UNREACHABLE() CCTK_Abort(0, 1) +# define __builtin_unreachable() CCTK_BUILTIN_UNREACHABLE() #endif /* Whether static_assert exists. */ #undef HAVE_CCTK_CXX_STATIC_ASSERT #ifdef HAVE_CCTK_CXX_STATIC_ASSERT -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1379> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1195: Modify bisection algorithm in EOS_Omni's nuc_eos
by Einstein Toolkit 07 Jul '13

07 Jul '13

#1195: Modify bisection algorithm in EOS_Omni's nuc_eos -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- EOS_Omni's nuc_eos routines use a bisection method to find the temperature for a given internal energy. This bisects on the temperature T. I suggest to bisect on log T instead, which is a more natural operation. For example, if the temperature range is [1...1000] in some units, then bisecting in T will examine the sequence 500, 250, 125, ..., and will thus perform many table lookups until (say) T=10 is reached. Bisecting in log T will find this result much faster. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1195> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1380: Support __builtin_assume_aligned
by Einstein Toolkit 07 Jul '13

07 Jul '13

#1380: Support __builtin_assume_aligned -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- The builtin assume_aligned tells the compiler that a certain pointer is aligned. This can lead to more efficient code when auto-vectorization is used. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1380> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #447: simfactory 1.0 always uses -L 3
by Einstein Toolkit 06 Jul '13

06 Jul '13

#447: simfactory 1.0 always uses -L 3 ----------------------------------------------+----------------------------- Reporter: alexander.beck-ratzka@… | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ----------------------------------------------+----------------------------- The perl version of simfactory always uses the debugging loglevel for simulations. The loglevel of a cactus simulation can be specified by setting -L to a value between 0 (none) and 3 (debug). While the cactus default is 0, simfactory sets it to 3. The debug loglevel could lead to huge output files. I would suggest to set it to the cactus default, and allow a user to increase it. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/447> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #107: Update released einsteintoolkit.bib once we have a more final version
by Einstein Toolkit 06 Jul '13

06 Jul '13

#107: Update released einsteintoolkit.bib once we have a more final version -----------------------+---------------------------------------------------- Reporter: anonymous | Type: task Status: new | Priority: major Milestone: | Component: EinsteinToolkit website Version: | Keywords: -----------------------+---------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/107> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1299: Correct ET logo on https://www.ohloh.net/p/einsteintoolkit
by Einstein Toolkit 06 Jul '13

06 Jul '13

#1299: Correct ET logo on https://www.ohloh.net/p/einsteintoolkit ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | ----------------------+----------------------------------------------------- The Einstein Toolkit logo on <https://www.ohloh.net/p/einsteintoolkit> looks bad, because it has the wrong aspect ratio. We should upload a square logo instead. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1299> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #346: Detect when --reconfig is necessary
by Einstein Toolkit 06 Jul '13

06 Jul '13

#346: Detect when --reconfig is necessary ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | ----------------------+----------------------------------------------------- Cactus sometimes outputs an error message that a configuration needs to be reconfigured. Simfactory should notice this, and then automatically build with --reconfig. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/346> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1065: Pass CCTK_ARGUMENTS more efficiently in Fortran
by Einstein Toolkit 06 Jul '13

06 Jul '13

#1065: Pass CCTK_ARGUMENTS more efficiently in Fortran -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- CCTK_ARGUMENTS is passed differently in C and in Fortran. In C, only a single pointer is passed, pointing to cctkGH. The cctk_... variables and pointers to grid functions are defined locally from cctkGH. This is efficient, because (a) only a single variable is passed, and (b) the compiler can eliminate unused definitions. In Fortran, all the cctk_... variables and all grid functions are passed explicitly. This is expensive for the caller, because hundreds of arguments have to be set up and passed to the subroutine. The compiler cannot eliminate any unused variables. I suggest to change the Fortran calling convention to be the same as the one for C. Since regular Fortran pointers differ significantly from C pointers, I suggest to use "Cray pointers" instead, which are very similar to C pointers. Cray pointers are an extension to the Fortran standard, and are supported by all Fortran compilers I know of. I attach sample code that shows how to declare, define, and use this convention. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1065> 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 June 2013