Trac August 2011

trac@lists.einsteintoolkit.org

1 participants
182 discussions

[Einstein Toolkit] #206: Add --xml option to GetComponents
by Einstein Toolkit 19 Oct '11

19 Oct '11

#206: Add --xml option to GetComponents ---------------------------+------------------------------------------------ Reporter: eric9 | Owner: eric9 Type: enhancement | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ GetComponents should support machine readable output using XML. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/206> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #481: Tests should be converted to use new symmetry thorns
by Einstein Toolkit 19 Oct '11

19 Oct '11

#481: Tests should be converted to use new symmetry thorns -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- It was decided (http://cactuscode.org/pipermail/developers/2010-September/006087.html) that the built-in CartGrid3D symmetries are deprecated and will not work with the Mercurial version of Carpet. Any test cases that use Grid::domain != "full" should be modified to use ReflectionSymmetry instead. In general, this should be possible without regenerating the test output. However, for the case of AHFinderDirect, the horizon finder actually uses a different internal multipatch grid structure if it detects that a CartGrid3D symmetry is being used. This means that the horizon shapes and quantities are different at the level of numerical error with ReflectionSymmetry. I propose to convert the tests to use ReflectionSymmetry and regenerate the test data (the grid function phi is the same with the new symmetry thorn, it's only the horizons which are different). The failing tests are related to checkpoint and recovery, and are not designed to test the symmetry mechanism. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/481> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #395: Thorns providing interpolator routines should provide testcases for them
by Einstein Toolkit 18 Oct '11

18 Oct '11

#395: Thorns providing interpolator routines should provide testcases for them -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: ET_2011_11 Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- Errors in the interpolator often show up in the output of other thorns, depending on those interpolating routines. Figuring out that this is caused by problem while interpolating can take quite a bit of time, which could be saved if the interpolating thorns would include testsuites themselves. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/395> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #369: Add command to update thorn list
by Einstein Toolkit 18 Oct '11

18 Oct '11

#369: Add command to update thorn list ---------------------------+------------------------------------------------ Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ When the thorn list changes, then I have to run GetComponents --update twice: first to update the thorn list, and then to actually check out these thorns. Currently, I have to update all thorns twice, which is a waste of time. Ideally, GetComponents would first update the thorn list, then update itself, then update everything else, and thus perform three passes over the thorn list, but not perform the work three times. Can we achieve this somehow? For example, we could mark the CRL script and the thorn lists with special tags, and GetComponents would then perform the work in three stages, restarting in between. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/369> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #379: Python simfactory branch has a confusing name
by Einstein Toolkit 04 Oct '11

04 Oct '11

#379: Python simfactory branch has a confusing name ------------------------+--------------------------------------------------- Reporter: hinder | Owner: mthomas Type: defect | Status: new Priority: minor | Milestone: ET_2011_11 Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- The python version of simfactory is currently on the branch PYSIM_2010. This should be just PYSIM. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/379> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #112: Python version of Simfactory should be made default before next ET release
by Einstein Toolkit 29 Sep '11

29 Sep '11

#112: Python version of Simfactory should be made default before next ET release ------------------------+--------------------------------------------------- Reporter: knarf | Owner: mthomas Type: task | Status: new Priority: critical | Milestone: ET_2011_06 Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/112> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #521: Test WeylScal4/teukolskyID is failing
by Einstein Toolkit 29 Sep '11

29 Sep '11

#521: Test WeylScal4/teukolskyID is failing -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: WeylScal4 testsuite | -----------------------------------+---------------------------------------- The !WeylScal4/teukolskyID test case run on 08-Aug-2011 failed. http://damiana2.aei.mpg.de/~ianhin/testsuites/einsteintoolkit/ The errors are related to nontrivial changes in Psi4: http://damiana2.aei.mpg.de/~ianhin/testsuites/einsteintoolkit/einsteintoolk… This is likely related to changeset:"62/ADMBase" committed as a result of #333. User: hinder Date: 2011/08/17 05:07 PM Modified: /trunk/ interface.ccl /trunk/src/ !InitSymBound.c Log: Apply "flat" boundary condition instead of "none" to ADMBase variables In the development version of Carpet, only the interior of the newly created grid is initialized by interpolation, so non-trivial boundary conditions need to be applied. I don't know whether the old or the new results are correct. The failure happens with the stable version of Carpet (the test has always failed with the development version). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/521> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #510: Reduce default verbosity
by Einstein Toolkit 28 Sep '11

28 Sep '11

#510: Reduce default verbosity -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- SimFactory has an option --verbose which defaults to True. This has been useful while SimFactory was in heavy development and there were frequent problems and errors where the extra information provided by --verbose gave useful context to debugging. Now that SimFactory is in regular production use with fewer problems, and the plan is to make it the default for the Einstein Toolkit, I propose to change the verbosity to False. This makes the tool appear less intimidating for new users and leads to an overall smoother, slicker experience. All information should be available in the simulation log file for debugging purposes if required. The attached patch implements this. There are still some messages which are output anyway, and these will need to be addressed one by one. Also, the --verbose setting does not appear to propagate across remote invocations of simfactory. But these are separate from the decision to make --no-verbose the default. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/510> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #131: Cactus produces way too much output with SILENT!=no
by Einstein Toolkit 26 Sep '11

26 Sep '11

#131: Cactus produces way too much output with SILENT!=no -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- I frequently find me scrolling through a lot of not necessary output from Cactus, including a lot of divider lines (___). I propose a mechanism to disable most of that output. There is currently one parameter which influences the amount of output from Cactus. If SILENT is set to 'no', Cactus provides way more output. All other values produce the usual output (including not setting it). I propose to use this existing variable to make Cactus less verbose if SILENT ist set to 'yes'. The default is 'undefined', so this would preserve the default Cactus behaviour. The attached patch attempts to do this: it suppresses divider lines, pre- and postprocessing infos if SILENT='yes'. I don't like that name though, as this is still not really silent, as you will still see one line per compiled file (ala COMPILING /home/frank.loeffler/mcrt/src/main/Banner.c), but I don't have a better idea right now and could live with it. The other option would be to introduce another variable (e.g. BRIEF), but then BRIEF and SILENT could contradict each other. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/131> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #444: Code documentation for Carpet
by Einstein Toolkit 25 Sep '11

25 Sep '11

#444: Code documentation for Carpet -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- Doxygen is a program which generates HTML documentation describing all the files, functions and classes of a program based on the C++ source. It uses comments in a particular format in the code. There is a search box and a tree view for the classes, as well as links to HTML versions of the source files. An example of the output is at http://damiana2.aei.mpg.de/~ianhin/carpet-doc/ To generate the documentation, go into the root Carpet directory and type "doxygen", assuming that doxygen is installed on the local system. The documentation will be generated in a new carpet-doc directory. Open the file carpet-doc/html/index.html to browse the documentation. It would be convenient to have the documentation generated in this way made available on the Carpet web site and updated after each commit to the repository. The attached patch provides a doxygen configuration file and a header file for the main documentation page. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/444> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

← Newer
1
...
8
9
10
11
12
13
14
...
19
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2011