Trac August 2013

trac@lists.einsteintoolkit.org

1 participants
148 discussions

[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] #1398: make evolution_method etc. parameters of ADMBase steerable
by Einstein Toolkit 25 Aug '13

25 Aug '13

#1398: make evolution_method etc. parameters of ADMBase steerable -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: ADMBase | -----------------------------------+---------------------------------------- this is occasionally useful to continue a run that started in Cowling approximation using a spacetime thorn (or the other way around, continue in cowling once the spacetime settles down to a stationary state). The attached patch makes all but the initial data parameters of admbase steerable on recovery. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1398> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1254: Simplify SimFactory's get-output-dir command
by Einstein Toolkit 19 Aug '13

19 Aug '13

#1254: Simplify SimFactory's get-output-dir command -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Currently, sim get-output-dir returns: {{{ Simulation name: <simname> Output directory: <basedir>/<simname>/output-NNNN/<parbasename> }}} I think most uses of this command would be in shell scripts, where it would be easier to use if it only output the actual output directory. The first line is redundant, as the user has already specified the simulation name. Also, simfactory is appending the <parbasename>, and assuming that such a directory exists and contains some useful data. Without parsing the parameter file and duplicating cactus logic, it cannot know where the actual data is. I think simfactory should just give the output-0000 directory, and leave it up to the user to figure out where to find the data in there. The attached patch implements this change. OK to apply? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1254> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1428: remove some Carpet build warnings, add run-time warnings about grid structure dataset
by Einstein Toolkit 18 Aug '13

18 Aug '13

#1428: remove some Carpet build warnings, add run-time warnings about grid structure dataset --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- the attached patch adds a level 2 warning when CarpetIOHDF5 cannot read the grid structure attribute (actually a dataset but treated as an attribute) in hdf5 files. This can happen if very old files (pre grid structure version 5) are being read or files that do not have the attribute at all. The attribute is used by the checkpoint recovery routine to reconstruct the process decomposition, but (as far as I know) ignored by the file reader for ID. There is also one bugfix in 0002 that makes it possible to read multipatch data into a cartesian simulation as ID by using only the cartesian patch. While the patch is fairly simple please comment on whether it is fine to move the calculation of upper/lower into the loop over local maps, given that the upper/lower values are those of the patch to be read from file. The reason for the move is that the calculation needs the stride which is read from the current simulation and not from the patch (and can only be gotten if the map in question actually exists). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1428> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1426: Fatal loopcontrol assertion causes 23 test failures
by Einstein Toolkit 15 Aug '13

15 Aug '13

#1426: Fatal loopcontrol assertion causes 23 test failures ----------------------+----------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: critical | Milestone: Component: Carpet | Version: development version Keywords: | ----------------------+----------------------------------------------------- A recent change has caused 23 of the tests to start failing: https://build.barrywardell.net/job/EinsteinToolkit/786/testReport/ One of the error messages is: {{{ /home/jenkins/workspace/EinsteinToolkit/arrangements/Carpet/LoopControl/src/loopcontrol.cc:795: void lc_control_init(lc_control_t*, lc_descr_t*, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t): Assertion `int(lc_fine_thread_comm.size()) < get_num_coarse_threads()' failed.cactus_sim: /home/jenkins/workspace/EinsteinToolkit/arrangements/Carpet/LoopControl/src/loopcontrol.cc:795: void lc_control_init(lc_control_t*, lc_descr_t*, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t): Assertion `int(lc_fine_thread_comm.size()) < get_num_coarse_threads()' failed. }}} Many others are similar. I assume that this affects non-test runs as well. The test system has been offline since 6th August due to server maintenance, so the error was introduced sometime between 6th and 15th August. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1426> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1427: Poloidal magnentic field warning should be output at run time, not at compile time
by Einstein Toolkit 15 Aug '13

15 Aug '13

#1427: Poloidal magnentic field warning should be output at run time, not at compile time -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- The warning /home/jenkins/workspace/EinsteinToolkit/arrangements/EinsteinInitialData/GRHydro_InitData/src/GRHydro_PoloidalMagFieldM.F90:110:2: warning: #warning "This algorithm does only work on Cartesian grids!!" [-Wcpp] should probably be output at run time, not only at compile time. (Of course, it would be even better if the code looked at the grid structure to determine whether the grid is Cartesian.) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1427> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1421: GetComponents shows uninitialized variable due to typo
by Einstein Toolkit 13 Aug '13

13 Aug '13

#1421: GetComponents shows uninitialized variable due to typo ---------------------------+------------------------------------------------ Reporter: knarf | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: ET_2013_11 Component: GetComponents | Version: ET_2013_05 Keywords: ET_2013_05 | ---------------------------+------------------------------------------------ When trying to update from an existing checkout I got: {{{ Use of uninitialized value $, in concatenation (.) or string at /home/knarf/bin/GetComponents line 1632, <STDIN> line 1. }}} This is caused by a typo (an additional "$") in the script. However, I found that one of the arguments in the relevant comparison also needs a 'chomp' to compre successfully, which I also added in the attached patch that I propose to also apply to the last release. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1421> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2013