Trac December 2011

trac@lists.einsteintoolkit.org

4 participants
150 discussions

[Einstein Toolkit] #652: CACTUS_CONFIGS_DIR should be documented
by Einstein Toolkit 23 Oct '13

23 Oct '13

#652: CACTUS_CONFIGS_DIR should be documented -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- At the moment CACTUS_CONFIGS_DIR is only mentioned in doc/FAQ. It should be documented in the regular documentation as well. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/652> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #605: Simfactory does not find the right 'path' for symlinked cactus directories
by Einstein Toolkit 13 Aug '13

13 Aug '13

#605: Simfactory does not find the right 'path' for symlinked cactus directories ------------------------+--------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: ET_2011_10 Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- Simfactory currently does not detect the 'right' path to a Cactus sourcetree if this is from within a symlink, e.g. Cactus -> /mnt/data/Cactus. This is because while `pwd` returns '/home/user/Cactus', simfactory uses a wrapper to the C-library getcwd(), which dereferences symlinks. Simfactory then gets '/mnt/data/Cactus' and tries to use this path on remote machines when syncing - which of course does not work. The attached patch fixes this by using os.environ.get("PWD") and, if this is not defined, using os.getcwd() as workaround. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/605> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 27

[Einstein Toolkit] #117: Error while building multiple configurations
by Einstein Toolkit 12 Aug '13

12 Aug '13

#117: Error while building multiple configurations ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- I wanted to build multiple configurations at once with the command ./simfactory/sim build sim-debug sim sim-debug is a debug configuration, sim is optimised. SimFactory built sim-debug, then aborted with the error: optionlist is: /Users/eschnett/EinsteinToolkit-hg/configs/sim/OptionList Error: pattern '^\s*DEBUG\s*=.*$' exists already It assumes that SimFactory doesn't properly distinguish between the different build options of the different configurations. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/117> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[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] #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] #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] #478: add Cactus to tis.xsede.org
by Einstein Toolkit 06 Jul '13

06 Jul '13

#478: add Cactus to tis.xsede.org --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: task | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/478> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #450: Output elapsed times for test cases
by Einstein Toolkit 06 Jul '13

06 Jul '13

#450: Output elapsed times for test cases -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- To ensure that Cactus test cases don't run for too long, and to identify those that do, we should output the run time for all test cases together with their results. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/450> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #229: Using a nonexistent header file should lead to an error message
by Einstein Toolkit 06 Jul '13

06 Jul '13

#229: Using a nonexistent header file should lead to an error message --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- If I have the following in my interface.ccl, USES INCLUDE: vectors.h but no thorn in my thornlist provides this header file, there is no error at compile time. Further, if I #include this file in my source file, an empty file is included, which means that again I don't get an error. The first indication that something is wrong is that the contents of the header file are not available, which makes debugging the problem with the thornlist very confusing. I propose that the CST should emit a fatal error if one of the thorns tries to use a header file which does not exist. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/229> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

← Newer
1
2
3
4
5
6
7
...
15
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac December 2011