Trac January 2012

trac@lists.einsteintoolkit.org

1 participants
151 discussions

[Einstein Toolkit] #392: Strange message "already on master"
by Einstein Toolkit 07 Nov '13

07 Nov '13

#392: Strange message "already on master" ---------------------------+------------------------------------------------ Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ GetComponents outputs "already on master" for every git repository. This message should not appear. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/392> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #626: Recovery fails in AHFinderDirect RecoverML with out-of-bounds assertion in CarpetLib
by Einstein Toolkit 28 Oct '13

28 Oct '13

#626: Recovery fails in AHFinderDirect RecoverML with out-of-bounds assertion in CarpetLib --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: ET_2011_10 Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- when trying to recover in AHFinderDirect's RecoverML test (parfiles attached) I get: {{{ cactus_et: /home/rhaas/ET_2011_10/arrangements/Carpet/CarpetLib/src/th.hh:79: double th::get_time(int, int, int) const: Assertion `tl>=0 and tl<timelevels' failed. }}} After some debuggin I traced this down to the metric which in CarpetIOHDF5/src/Input.cc:762 is reported (by gf->timelevels (ml, rl)) to have three timelevels. However the timelevels member of gf->t (a th) gives the number of timelevels as two {{{ gf->t.timelevels $28 = 2 }}} Since timelevels is new in Carpet/Hg my suspicion would be that it is not properly updated when gf->set_timelevels is called (the comments in th.hh seem to indicated that it is assumed to be const which seems odd given that ggf::set_timelevels exists). I don't understand enough of Carpet to fix or further debug this. Marking its as major and release relevant in case it is actually a Carpet bug. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/626> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 21

[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

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac January 2012