Trac August 2011

trac@lists.einsteintoolkit.org

1 participants
182 discussions

[Einstein Toolkit] #241: Thorns should be able to specify implementation versions, and other thorns should be able to depend on those
by Einstein Toolkit 26 Oct '15

26 Oct '15

#241: Thorns should be able to specify implementation versions, and other thorns should be able to depend on those -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Cactus thorns implement 'implementations', and other thorns can then depend on particular implementations being present. However, quite often those are updated, and incompatibilities occur. Usually this is resolved by the developer in both thorns - the implementing and the using thorn. However, a user might just update one of them, and Cactus would not catch this error. Thus, I suggest to think about, and implement how to: - specify implementation versions e.g. IMPLEMENTS: Cactus (4.0) The version string within () would have be sorted in an intelligent way to allow comparisons [1]. - specify dependencies on particular versions of other implementations In particular I suggest the following dependencies: depends, and conflicts, both with comparisons < <= == >= > != e.g. DEPENDS: Cactus (>= 4.0) DEPENDS: BadImplementation (!=3.14) <-- this introduces a dependency CONFLICTS: BadImplementation (==3.14) <-- this doesn't introduce a depencency [1] First the initial part of each string consisting entirely of non-digit characters is determined. These two parts (one of which may be empty) are compared lexically. If a difference is found it is returned. The lexical comparison is a comparison of ASCII values modified so that all the letters sort earlier than all the non-letters. Then the initial part of the remainder of each string which consists entirely of digit characters is determined. The numerical values of these two parts are compared, and any difference found is returned as the result of the comparison. For these purposes an empty string (which can only occur at the end of one or both version strings being compared) counts as zero. These two steps (comparing and removing initial non-digit strings and initial digit strings) are repeated until a difference is found or both strings are exhausted. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/241> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 27

[Einstein Toolkit] #334: unsuccessful qsub not recognized / submit succeeds for finished simulation
by Einstein Toolkit 18 Aug '15

18 Aug '15

#334: unsuccessful qsub not recognized / submit succeeds for finished simulation ------------------------+--------------------------------------------------- Reporter: knarf | Owner: mthomas Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- python version: I submitted a simulation 'sim submit' but the corresponding qsub failed due to wrong numbers of procs/node (philip cluster). I changed the number given on the command line and did a 'sim submit' again, this time successful. Several things happend which I think could be done better: - the unsuccessful qsub was not detected during the new submit - it attempted a restart and didn't simply clean the unsuccessful submit - when trying the restart, it went ahead and queued the job, but this later failed when run with "cannot rerun a restart that has been finished". This could have been caught earlier - without the wait time in the queue. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/334> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #428: Forbid configuration names ending in -reconfig
by Einstein Toolkit 12 Jan '15

12 Jan '15

#428: Forbid configuration names ending in -reconfig ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- I accidentally created a Cactus configuration with a name like "sim- reconfig". This confuses Cactus, because the command "make sim-reconfig" can then mean either to build the "sim-reconfig" configuration, or to reconfigure the "sim" configuration. Cactus should catch and forbid these cases. This is probably most cleanly handled by using a script instead of a Makefile to interpret the user commands. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/428> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #499: Prolongation fails with vectorisation enabled
by Einstein Toolkit 25 Aug '14

25 Aug '14

#499: Prolongation fails with vectorisation enabled --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- The development version of Carpet uses vectorisation to speed-up prolongation. This fails with various errors, including corruption of the malloc heap. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/499> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 23

[Einstein Toolkit] #445: Make Carpet timers hierarchical
by Einstein Toolkit 25 Aug '14

25 Aug '14

#445: Make Carpet timers hierarchical -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- With the current flat structure of timers in Carpet, it is difficult to identify which timers are contained in which other timers, and hence to avoid double-counting when adding up the times. This series of patches modifies the timer infrastructure in Carpet to generate a tree of timers where the hierarchy reflects the call-graph of the program. This makes it much easier to interpret the timer output than with the previous flat structure, where it was not possible to see which timers "contained" which others. More implementation details are given at the top of TimerNode.hh. Note that the Timer source and header files have been renamed as CactusTimer and a new Timer file and object has been created. This is because the Timer object now only provides a wrapper around the Cactus timer mechanism which was contained in the old Timer object. New parameters output_initialise_timer_tree and output_timer_tree_every control output of a new "timer tree diagram" to standard output for the Initialise and Evolve timer trees respectively. These diagrams indicate: 1. the value of each timer; 2. the percentage of the given tree taken by each timer; 3. which timers are contained in which other timers; 4. any untimed code for any timer which takes more than 1% of the tree time. Making the timers hierarchical means that the ad-hoc methods used before to identify the hierarchy (such as naming the timer Evolve::Sync, for example, to indicate that the Sync timer was a child of the Evolve timer) are no longer necessary and have been removed. Additionally, the construction of timers in a "dynamic" manner is now handled automatically for all timers, so special-case code is no longer needed and has been removed. Additionally some previously-untimed parts of the code are now timed, and timer names have been made more consistent in some places. There is code in the patches to output the entire timer tree as an XML file, but it is not enabled. Ideally the timer tree printed to standard output would contain reductions across processes, but at the moment it contains only the timer from the current process. The attached "tree-example.txt" file shows an example of the timer tree that is printed for a simulation using the qc0-mclachlan parameter file from the Einstein Toolkit. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/445> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #542: Remove thorn CactusArchive/ADM from thorn list
by Einstein Toolkit 25 Jan '14

25 Jan '14

#542: Remove thorn CactusArchive/ADM from thorn list -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: task | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Remove thorn CactusArchive/ADM from thorn list. This thorn is outdated, and we should updated out test cases instead. It also takes a long time and a lot of memory to compile. If we want an ADM formulation (which is doubtful since we don't use it ourselves), we should implement one via Kranc. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/542> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #114: per-variable tolerances for Cactus testsuites
by Einstein Toolkit 24 Jan '14

24 Jan '14

#114: per-variable tolerances for Cactus testsuites -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: major | Milestone: ET_2011_06 Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- It would be nice to be able to specify per-variable testsuite tolerances in Cactus (per regexp for the name in the ideal case). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/114> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 24

[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] #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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2011