Trac September 2013

trac@lists.einsteintoolkit.org

1 participants
141 discussions

[Einstein Toolkit] #1392: loopcontrol outputs nan values
by Einstein Toolkit 28 Oct '13

28 Oct '13

#1392: loopcontrol outputs nan values --------------------+------------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: ET_2013_11 Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- After a recent update of carpet, some of my par files produce output like this: {{{ INFO (LoopControl): LoopControl statistics: INFO (LoopControl): Loops traversed: 4 INFO (LoopControl): Setups encountered: 14 INFO (LoopControl): Params explored: 14 INFO (LoopControl): Unoptimized time would have been: -nan s INFO (LoopControl): Actual time spent: -nan s (-nan%) INFO (LoopControl): Ideal time could have been: -nan s (-nan%) }}} Although no problem for the run, the 'nan's should probably not be output in that way. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1392> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1251: Use Parsing Expression Grammar for Par Files
by Einstein Toolkit 28 Oct '13

28 Oct '13

#1251: Use Parsing Expression Grammar for Par Files -------------------------+-------------------------------------------------- Reporter: sbrandt | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- Piraha is a parsing framework/library based on Parsing Expression Grammars (PEGs). This allows you to define the grammar of a language using a simple regular-expression-type language, and Piraha will use this to decode an input file into a hierarchical data structure of the parsed data (a "parse tree"). See http://code.google.com/p/piraha-peg/, http://en.wikipedia.org/wiki/Parsing_expression_grammar. I've hacked a version of Cactus to use Piraha for parameter parsing. Please take a look: https://svn.cactuscode.org/flesh/branches/with_piraha This version is able to run the ET testsuite. This version can understand the variables $parfile, $ENV{name}, and $pi (which is 3.14...). Variables can be standalone, or be substituted from inside strings. It can understand mathematical expressions including grouping, order of operation, and a few functions (sin, cos, tan, exp, sqrt). Other parameters from the parameter file are available for use in mathematical expressions. Some debug printing is in place so you can get an idea of what's going on. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1251> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1425: git repositories checkout into main tree
by Einstein Toolkit 28 Oct '13

28 Oct '13

#1425: git repositories checkout into main tree ---------------------------+------------------------------------------------ Reporter: knarf | Owner: eric9 Type: enhancement | Status: new Priority: major | Milestone: ET_2013_11 Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ GetComponents should only use 'repos' for git clones if it has to, i.e., if the thorn/arrangement is deeper within the repository. If the repository only contains one thorn, and that thorn is what should be checked out, then we should check it out directly into its arrangement. Also, if we are going to have arrangement-repos in the future, these should also be checked out directly into the main tree. We need to figure out how to teach this to GetComponents, while still telling Cactus about all the contained thorns it should build. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1425> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1066: Implement IMEX integrators in MoL
by Einstein Toolkit 25 Oct '13

25 Oct '13

#1066: Implement IMEX integrators in MoL -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Dana Alic contributed an implementation of IMEX integrators for MoL. I attach the implementation as a patch (based on r133 of MoL). The implementation is well tested. The patch does not apply cleanly, and seems to make some modifications to the schedule etc. as well that have since been superseded by other changes to MoL. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1066> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[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] #1429: Assertion error when using "eval" & new UIUC speedup in TwoPunctures
by Einstein Toolkit 23 Oct '13

23 Oct '13

#1429: Assertion error when using "eval" & new UIUC speedup in TwoPunctures --------------------------------------+------------------------------------- Reporter: bernard.j.kelly@… | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2013_11 Component: EinsteinToolkit thorn | Version: development version Keywords: TwoPunctures, malloc | --------------------------------------+------------------------------------- Hi. The new, more efficient, "eval" branch of TwoPunctures is generating a problem in certain cases. I had a job using this code (brought over from the trunk to my ET_2013_05 release), and it failed with an assertion error in TP_utilities.c, within the "d3tensor" allocation routine. I'm attaching a sample parameter file and the associated SCROUT + SCRERR for a small version of this case. It was run on 2 Nehalem nodes (8 cores each; no OpenMP), using an executable compiled with -O3 level optimisation using Intel-2013 compilers and SGI's MPT implementation of MPI. Here's the actual error message in the SCROUT+ERR file: {{{ TP_utilities.c:146: TP_d3tensor: Assertion `retval[i][nch]-retval[i][ncl] == (nch-ncl)*depth' failed. }}} I've looked at the d3tensor allocation routine in TP_utilities.c, and it seems to have several problems: * it has an actual bug in line 115: {{{ retval[0][0] = malloc(sizeof(CCTK_REAL)*(nrh-nrl+1)*(nch-ncl+1)*(nrh- nrl+1)); }}} --- the last factor should be (ndh-ndl+1), ''not'' (nrh-nrl+1) * even without that bug, the size allocated is too long by one in each dimension, when called by other TP routines, as, in fact, are *all* these TP_utilities routines. * the way in which memory is allocated seems to assume contiguous memory chunks (I suspect this is the real problem, given the error message). * all the routines in TP_utilities.c use "int" and "long" instead of "CCTK_INT" -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1429> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 17

[Einstein Toolkit] #963: Improve McLachlan accuracy
by Einstein Toolkit 15 Oct '13

15 Oct '13

#963: Improve McLachlan accuracy -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- James van Meter provided me with an optimised version of McLachlan. He states: 1. You are not taking full advantage of the chi=exp(-2phi) variable. There are several terms you divide by chi or chi^2 in expressions with overall factors exp(-4phi). I rewrote the BSSN equations to make these cancellations before coding. So where you have an expression of the form chi^2(A+B/chi^2), I have chi^2A+B. This gives a slight but noticeable advantage in both accuracy and performance. 2. I added Hamiltonian-constraint-damping terms due to Duez et al. These terms don't seem to be well-known but they are effective. 3. I added a Gamma-constraint-damping term due to Yo et al. 4. I enforce det(g)=1. I have not tested this new version yet, but James suggests to include it into the Einstein Toolkit. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/963> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

[Einstein Toolkit] #1372: AHFinderDirect/misner1.2-025 test fails on datura in ET_2013_05 release branch
by Einstein Toolkit 03 Oct '13

03 Oct '13

#1372: AHFinderDirect/misner1.2-025 test fails on datura in ET_2013_05 release branch -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: AHFinderDirect | -----------------------------------+---------------------------------------- AHFinderDirect/misner1.2-025 test fails on datura in ET_2013_05 release branch. Diffs are: {{{ BH_diagnostics.ah1.gp: differences below tolerance on 1 lines BH_diagnostics.ah2.gp: differences below tolerance on 1 lines h.t0.ah1.gp: differences below tolerance on 703 lines h.t0.ah2.gp: differences below tolerance on 698 lines sf_area[0].xg: differences below tolerance on 1 lines sf_min_radius[0].xg: differences below tolerance on 1 lines sf_radius[0]_2D.asc: differences below tolerance on 496 lines sf_radius[1]_2D.asc: substantial differences significant differences on 5 (out of 1058) lines maximum absolute difference in column 3 is 1.75718694541256e+243 maximum relative difference in column 3 is 2899588673.18783 (insignificant differences on 37 lines) }}} Since this does not fail in the ubuntu test VM, it might be something to do with the Intel compiler vs GCC. According to http://einsteintoolkit.org/release- info/parse_testsuite_results.php, it seems that this test was failing on a number of machines for a while. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1372> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1412: Memory leak on development branch
by Einstein Toolkit 30 Sep '13

30 Sep '13

#1412: Memory leak on development branch -----------------------------------+---------------------------------------- Reporter: hopper.seth@… | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: | -----------------------------------+---------------------------------------- I am seeing what appears to be a memory leak that has showed up since the Gauss release. I have run the same parameter file on Gauss and the development branch, and see linear growth in memory usage in the development version. From standard out it looks to be a bug in Carpet, as the memory usage jumps after re-gridding. I've attached: - The parameter file, bbhCart2-3.rpar. It runs on 12 cores on Datura. - Plots showing the memory usage per process in the two cases. - Standard out from the two cases. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1412> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 18

[Einstein Toolkit] #1445: add tags to disallow splitting in directions
by Einstein Toolkit 27 Sep '13

27 Sep '13

#1445: add tags to disallow splitting in directions -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | -------------------------+-------------------------------------------------- the attached patch adds a new tag "no_split_directions" which can be used to prevent a grid array to be split in the given directions when processor decompositions is done. I currently explicitly forbid this tag to be used in grid functions since all grid functions share the same processor decomposition so using this tag on a per-function basis is impossible. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1445> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac September 2013