Trac July 2012

trac@lists.einsteintoolkit.org

1 participants
161 discussions

[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] #874: Reduce warnings during an ET build
by Einstein Toolkit 12 Aug '13

12 Aug '13

#874: Reduce warnings during an ET build --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | --------------------+------------------------------------------------------- A new user of the ET might be disconcerted to see warnings during compilation such as: {{{ /home/ianhin/Cactus/EinsteinToolkit/arrangements/Carpet/CarpetLib/src/bboxset.hh(206): warning #1224: #warning directive: "TODO: this is incorrect" #warning "TODO: this is incorrect" ^ }}} I propose that such directives are replaced with a comment and a link to a TRAC ticket concerning the problem. Further, we should aim to eliminate as many warnings as possible from the build, similarly to avoid eroding confidence. Warnings can also make it hard to find the real error messages, when a build fails with errors. Other warnings I see are similar to: {{{ In file included from /home/ianhin/Cactus/GBSC12/arrangements/CactusUtils/Formaline/src/thornlist.cc:13: /home/ianhin/Cactus/GBSC12/configs/bbh/bindings/include/thornlist.h:61: warning: deprecated conversion from string constant to ‘char*’ }}} {{{ /home/ianhin/Cactus/GBSC12/arrangements/EinsteinInitialData/TwoPunctures/src/Newton.c: In function ‘TestRelax’: /home/ianhin/Cactus/GBSC12/arrangements/EinsteinInitialData/TwoPunctures/src/Newton.c:287: warning: passing argument 6 of ‘resid’ from incompatible pointer type /home/ianhin/Cactus/GBSC12/arrangements/EinsteinInitialData/TwoPunctures/src/Newton.c:75: note: expected ‘const int * const restrict* const restrict’ but argument is of type ‘int **’ }}} {{{ /home/ianhin/Cactus/GBSC12/configs/bbh/bindings/Variables/ADMBase.c: In function ‘CCTKi_BindingsFortranWrapperADMBase’: /home/ianhin/Cactus/GBSC12/configs/bbh/bindings/Variables/ADMBase.c:34: warning: passing argument 22 of ‘function’ from incompatible pointer type /home/ianhin/Cactus/GBSC12/configs/bbh/bindings/Variables/ADMBase.c:34: note: expected ‘const struct cGH * const*’ but argument is of type ‘struct cGH **’ }}} This last warning appears very many times during a build (though I believe it may be triggered only by GCC and not by the Intel compiler). {{{ /home/ianhin/Cactus/GBSC12/src/main/Parameters.c: In function ‘ParameterSetBoolean’: /home/ianhin/Cactus/GBSC12/src/main/Parameters.c:2394: warning: passing argument 4 of ‘Util_ExpressionEvaluate’ discards qualifiers from pointer target type /home/ianhin/Cactus/GBSC12/src/include/util_Expression.h:38: note: expected ‘void *’ but argument is of type ‘const int *’ }}} There are probably more as well. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/874> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[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] #907: TRAC: allow to create a ticket with review state
by Einstein Toolkit 06 Jul '13

06 Jul '13

#907: TRAC: allow to create a ticket with review state ----------------------------------+----------------------------------------- Reporter: bmundim | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit trac | Version: Keywords: TRAC | ----------------------------------+----------------------------------------- Sometimes we want to create a ticket with an attached patch and assign the ticket to be reviewed. That should be possible with only one "modify ticket". Currently we need to create the ticket with the attachment and then modify the ticket afterwards to review state. The problem is that sometimes we forget to change to review state. It would be nice to do it all at once. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/907> 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

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac July 2012