Trac September 2012

trac@lists.einsteintoolkit.org

1 participants
182 discussions

[Einstein Toolkit] #1108: Formaline should also work with globally installed simfactory
by Einstein Toolkit 08 Oct '12

08 Oct '12

#1108: Formaline should also work with globally installed simfactory --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: ET_2012_11 Component: Other | Version: development version Keywords: | --------------------+------------------------------------------------------- Currently, Formaline doesn't find a globally installed simfactory. The build succeeds, but produces error messages close to the end like sh: 1: /home/knarf/Cactus/bin/sim: not found The attached patch tries, after not finding 'sim' in that location simply 'sim' - to be searched for in the users' search path. It also redirects stderr of the first (but not second) try to /dev/null to avoid these error messages. It doesn't do this for the second try to make sure the users sees 'something' which points towards Formaline not finding something. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1108> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #1106: Possible issue in TmunuBase with support_old_CalcTmunu_mechanism=no
by Einstein Toolkit 25 Sep '12

25 Sep '12

#1106: Possible issue in TmunuBase with support_old_CalcTmunu_mechanism=no -----------------------------------------+---------------------------------- Reporter: wolfgang.kastaun@… | Type: defect Status: new | Priority: minor Milestone: | Component: EinsteinToolkit thorn Version: development version | Keywords: -----------------------------------------+---------------------------------- I think the schedule of the AddToTmunu should be changed from SCHEDULE GROUP AddToTmunu IN SetTmunu AFTER TmunuBase_SetTmunu to SCHEDULE GROUP AddToTmunu IN SetTmunu AFTER (TmunuBase_SetTmunu TmunuBase_ZeroTmunu) since with support_old_CalcTmunu_mechanism=no, Tmunu is initialised by TmunuBase_ZeroTmunu and not by TmunuBase_SetTmunu. Otherwise, it could happen that thorns add to undefined value and afterwards Tmunu is set to zero. This did not happen to me yet, but probably only by luck. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1106> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1104: create "current-release" branch for all ET components
by Einstein Toolkit 22 Sep '12

22 Sep '12

#1104: create "current-release" branch for all ET components -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- right now with each release we have to manually change all references from eg. 2012_05 to 2012_11 and are likely to miss one somewhere. It might be convenient to have a (symbolic link like) branch "current-release" (or so) that always points to the last stable release. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1104> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1101: Test system output format should be extensible and easy to parse programmatically
by Einstein Toolkit 19 Sep '12

19 Sep '12

#1101: Test system output format should be extensible and easy to parse programmatically -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- The Cactus test system currently outputs a human-readable results file. It is necessary to write a simple parser for this file (e.g. in Perl or Awk) in each application that needs to understand the results. Because the output format is not extensible, it is difficult to add test-specific details in a way which does not break exising ad-hoc parsers. I propose that the test system should output its results in XML format in addition to the current format. This format is extensible and parsers exist for most languages. I started to work on this a while ago, but have not had time to complete it. I attach a work-in-progress patch against revision 4874 of Cactus; I don't remember its status. It uses an imported Perl XML writer module (included in the patch) which seems to have a suitable licence. Since writing this, I have learned that test systems often write their output in a format compatible with the JUnit Java testing framework. As far as I can tell, this is not an officially defined format, but it is understood by many test systems (e.g. Jenkins, which I have been using recently). The code in the attached patch should be modified to output in this format. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1101> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #720: check at runtime that all REQUIREd and OPTIONAL thorns and capabilities are active
by Einstein Toolkit 19 Sep '12

19 Sep '12

#720: check at runtime that all REQUIREd and OPTIONAL thorns and capabilities are active -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- This is an offshot of a discussion on the Cactus developers mailing list: http://cactuscode.org/pipermail/developers/2011-November/006258.html On 6 Jan 2012 12:54:13 -0500 eschnett said: > What is currently missing is the mechanism that checks that all thorns > providing required capabilities are activated. If they are not, code > in inactive thorns is called -- this is fine as long as no Cactus > infrastructure is used (parameters, scheduled routines, grid > functions, etc.). > > Yes, we should implement the respective checks; yes, we should > automatically activate thorns required for capabilities (and maybe > some others as well?); yes, we should then output this thorn list to > the screen (done anyway) and into a file. > > By the way, Cactus already determines which thorns need to be > activated automatically as a service to the user in the error message > that complains about missing thorns. The idea seems to be to document all thorns whose code is executed in the parameter file. Ian's original need might be served by an "OPTIONAL" statement in configuration.ccl (http://einsteintoolkit.org/documentation/UsersGuide/UsersGuidech12.html#x17…) and some #ifdefs, maybe. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/720> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #929: GRHydro_test_tov_ppm_ML fails intermittently
by Einstein Toolkit 19 Sep '12

19 Sep '12

#929: GRHydro_test_tov_ppm_ML fails intermittently -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- The test GRHydro_test_tov_ppm_ML sometimes fails on Datura. This seems to be nondeterministic. The most recent occurrence of this (http://git.barrywardell.net/EinsteinToolkitTestResults.git/blob/0fed62edfcc…) is due to differences in the constraints and vel[0]_norm1.xg very close to the tolerance. This does not happen every time. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/929> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #988: testsuite can't find MPI when CACTUS_CONFIGS_DIR is set
by Einstein Toolkit 19 Sep '12

19 Sep '12

#988: testsuite can't find MPI when CACTUS_CONFIGS_DIR is set ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: Type: defect | Status: new Priority: minor | Milestone: Cactus_4.1.0 Component: Cactus | Version: development version Keywords: | ---------------------+------------------------------------------------------ testsuite can't find MPI when CACTUS_CONFIGS_DIR is set, a patch correcting this problem is attached -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/988> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1037: Update Fortran API for CCTK_LOOP macros
by Einstein Toolkit 19 Sep '12

19 Sep '12

#1037: Update Fortran API for CCTK_LOOP macros ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- The enclosed patch updates the Fortran API to be equivalent to the C API. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1037> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1098: Carpet does not set up the initial time properly
by Einstein Toolkit 18 Sep '12

18 Sep '12

#1098: Carpet does not set up the initial time properly --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- Carpet's Intialize.cc contains a typo that causes it to not properly set the times member of the intial time levels. Instead it stays the C++ default value of 0. The attached (trivial) patch fixes this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1098> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1052: use grid::x, x, y in CarpetIOASCII for x, y, z columns
by Einstein Toolkit 18 Sep '12

18 Sep '12

#1052: use grid::x,x,y in CarpetIOASCII for x,y,z columns -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- right now CarpetIOASCII computes the "local" coordinates from the lower boundary coordinate of each patch and CCTK_DELTA_SPACE. This does not work (as expected) for multipatch. It would be good to add an option to use grid::x etc instead. Ideally as both a parameter and an option in the '{}' to choose at runtime and per variable what to do (eg. to keep the r coordinate around for spherical patches). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1052> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

← Newer
1
...
12
13
14
15
16
17
18
19
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac September 2012