Trac April 2012

trac@lists.einsteintoolkit.org

1 participants
196 discussions

[Einstein Toolkit] #780: missing small packages
by Einstein Toolkit 29 Jul '13

29 Jul '13

#780: missing small packages ----------------------------------------------+----------------------------- Reporter: knarf | Owner: dcastl2 Type: enhancement | Status: new Priority: major | Milestone: Component: Einstein Toolkit Virtual Machine | Version: Keywords: | ----------------------------------------------+----------------------------- Some tools to be installed: mmv screen tmux texlive (probably quite large, but also probably necessary) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/780> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[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

[Einstein Toolkit] #705: Activation Order in Parameter Files
by Einstein Toolkit 24 May '13

24 May '13

#705: Activation Order in Parameter Files -------------------------+-------------------------------------------------- Reporter: sbrandt | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Cactus_4.1.0 Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- At the moment the ActiveThorns list is sensitive to the order in which thorns are activated if the ActiveThorns parameter is updated multiple times. However, it is not sensitive to the order in which thorns are activated if all thorns are specified in a single line. This inconsistency should be removed, and the order should not matter in either case. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/705> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #526: Reorder ticket states
by Einstein Toolkit 23 May '13

23 May '13

#526: Reorder ticket states ----------------------------------+----------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit trac | Version: Keywords: | ----------------------------------+----------------------------------------- The order in which the ticket states is displayed (in the form where one modifies the ticket state) should be the natural order in which a ticket progresses. The current order is somewhat random. I suggest this order: new confirmed accept reassign review resolve -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/526> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac April 2012