Trac December 2011

trac@lists.einsteintoolkit.org

4 participants
150 discussions

[Einstein Toolkit] #649: simfactory should create the "simulations" directory
by Einstein Toolkit 14 Aug '15

14 Aug '15

#649: simfactory should create the "simulations" directory ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- when following the new users tutorial one gets: {{{ [rhaas@qb1 Cactus]$ ./simfactory/bin/sim submit static_tov --parfile=par/static_tov.par --procs=32 --walltime=8:0:0 Parameter file: /home/rhaas/Cactus/par/static_tov.par Error: could not access simulation base directory /scratch/rhaas/simulations for reading and writing Aborting Simfactory. [137450 refs] }}} This happens each time I set up a fresh simfactory on a machine. It might be useful if simfactory would create the simulation base directory if it does not exist. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/649> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[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] #582: Semi-automatically split McLachlan's calculations
by Einstein Toolkit 08 Dec '14

08 Dec '14

#582: Semi-automatically split McLachlan's calculations -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Split McLachlan's calculations semi-automatically in two ways: (a) by variable, so that e.g. dot[g] and dot[K] are calculated separately, and (b) by pattern, so that advection terms, dissipation, and "everything else" are calculated separately. Also introduce parameters to choose which routines are called at run time. This is somewhat a work in progress, in that the patch is good, but the API defined to split kernels is more complex and less failsafe than it should be. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/582> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[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] #590: McLachlan should allow other thorns to set the gauge
by Einstein Toolkit 28 Apr '14

28 Apr '14

#590: McLachlan should allow other thorns to set the gauge -----------------------------------+---------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The parameters lapse_evolution_method and shift_evolution_method are usually set to ML_BSSN in McLachlan. However they are never checked in the code. McLachlan indeed seems to ignore their values and overwrite whatever the values of lapse or shift set elsewhere, preventing therefore other thorns from setting them differently. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/590> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 22

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac December 2011