Trac August 2017

trac@lists.einsteintoolkit.org

1 participants
102 discussions

[Einstein Toolkit] #2013: piraha breaks ThornDoc building
by Einstein Toolkit 19 Nov '17

19 Nov '17

#2013: piraha breaks ThornDoc building --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- Doing {{{make ThornDocHTML}}} I get an error message in eg in echo RELOADAGENT | gpg-connect-agent of {{{ Undefined subroutine &piraha::parse_peg_file called at /home/rhaas/postdoc/gr/cactus/ET_trunk/lib/sbin/ScheduleParser.pl line 83. }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2013> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #1396: Display prompts of executed commands
by Einstein Toolkit 19 Nov '17

19 Nov '17

#1396: Display prompts of executed commands ---------------------------+------------------------------------------------ Reporter: rhaas | Owner: eric9 Type: enhancement | Status: new Priority: optional | Milestone: Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ the attached patch goes to some lengths to capture both stdout and stderr when executing commands and displays each line of output as it is generated by the command. This is useful for programs that output prompts to stdout and wait for user input afterwards. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1396> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #2015: thorn Vectors does not provide a sum() reduction
by Einstein Toolkit 19 Nov '17

19 Nov '17

#2015: thorn Vectors does not provide a sum() reduction -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: Vectors | -------------------------+-------------------------------------------------- It would be very useful for some applications (eg interpolation) if thorn Vectors provided a sum() function similar to the sum() member of vecmathlib https://bitbucket.org/eschnett/vecmathlib/src/477f9c85cf111e59a9042f230bb53… =file-view-default#vec_avx_double4.h-537 {{{ real_t sum() const { // return (*this)[0] + (*this)[1] + (*this)[2] + (*this)[3]; // __m256d x = _mm256_hadd_pd(v, v); // __m128d xlo = _mm256_extractf128_pd(x, 0); // __m128d xhi = _mm256_extractf128_pd(x, 1); realvec_t x = *this; x = _mm256_hadd_pd(x.v, x.v); return x[0] + x[2]; } }}} Most likely one can just copy and paste the code from vecmathlib. vecmathlib's license is not LGPL but permissive enough for inclusion and we can also ask Erik if one can use it and change the license of the affected code lines to LGPL in Cactus, the license is here: https://bitbucket.org/eschnett/vecmathlib/src/477f9c85cf111e59a9042f230bb53… =file-view-default {{{ Copyright (c) 2012, 2013 Erik Schnetter <eschnetter(a)gmail.com> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2015> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #2026: param.ccl parser writes (debug?) files v1 and v2 into Cactus root
by Einstein Toolkit 19 Nov '17

19 Nov '17

#2026: param.ccl parser writes (debug?) files v1 and v2 into Cactus root --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- The file parametre_parser.pl contains {{{ open($fd,">v1") or die; print $fd $v1,"\n"; close($fd); open($fd,">v2") or die; print $fd $v2,"\n"; close($fd); }}} causing it to create files v1 and v2 in the main Cactus root. Without having looked into this in any more details, this smells like debug output that should be removed before the release. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2026> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #68: GetComponents hang due to certificate issues.
by Einstein Toolkit 19 Nov '17

19 Nov '17

#68: GetComponents hang due to certificate issues. --------------------------------+------------------------------------------- Reporter: diener@… | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: Component: GetComponents | Version: ET_2010_06 Keywords: | --------------------------------+------------------------------------------- I did a complete new checkout of the EinsteinToolkit on numrel06 using the version of GetComponents available on the EinsteinToolkit web pages and had GetComponents hang with no errors or warnings when checking out AEIThorns/AEILocalInterp. Trying the checkout manually I got: Error validating server certificate for 'https://svn.aei.mpg.de:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: svn.aei.mpg.de - Valid: from Tue, 23 Feb 2010 16:02:12 GMT until Sun, 22 Feb 2015 16:02:12 GMT - Issuer: Max-Planck-Gesellschaft, DE - Fingerprint: 03:b4:e8:6e:d9:09:e9:93:72:e9:ff:fa:df:e4:2c:6d:1d:2a:e4:66 (R)eject, accept (t)emporarily or accept (p)ermanently? p After accepting the certificate and restarting the checkout proceeded without problems. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/68> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 29

[Einstein Toolkit] #2076: fix stripping of sourcedir path
by Einstein Toolkit 19 Nov '17

19 Nov '17

#2076: fix stripping of sourcedir path ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: backport | ------------------------+--------------------------------------------------- Commit d6e4f58 - sim-sync: handle symbolic links more gracefully (1 year, 6 months ago) <Roland Haas> introduced a bug that manifest in error messages of the form "mkdir: cannot create directory `/ET_Hack': Permission denied". Pull request is https://bitbucket.org/simfactory/simfactory2/pull- requests/21/simlib-correct-stripping-of-first-part/diff This should be backported to the release as it is very annoying to not even be able to use sim sync to transfer code. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2076> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #181: AEILocalInterp should not off-centre the interpolation stencil by default
by Einstein Toolkit 19 Nov '17

19 Nov '17

#181: AEILocalInterp should not off-centre the interpolation stencil by default ----------------------------+----------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: AEILocalInterp | ----------------------------+----------------------------------------------- AEILocalInterp by default will off-centre the interpolation stencil if there are insufficient points to perform the interpolation. In a parallel setting, this could happen due to there being insufficient ghost points for the interpolator chosen. The off-centering leads to an interpolation error which is of the correct order but larger than for a centered stencil. More importantly, it leads to different results on different numbers of processes. This violates a basic design principle of Cactus, and the expectation of users, that changing the number of processors should not change the results of a simulation. I propose that instead of silently off-centering the stencil, AEILocalInterp should abort with an error indicating that there are insufficient ghost-zones. The interpolator options corresponding to this are: boundary_off_centering_tolerance={0.0 0.0 0.0 0.0 0.0 0.0} boundary_extrapolation_tolerance={0.0 0.0 0.0 0.0 0.0 0.0} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/181> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #2068: Support KNL's AVX512 instruction set
by Einstein Toolkit 06 Nov '17

06 Nov '17

#2068: Support KNL's AVX512 instruction set ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- The main point of this pull request is to support KNL's AVX512 instruction set. This pull request also contains a few other changes on which the AVX512 depends. See [https://bitbucket.org/cactuscode/cactusutils/pull-requests/13 /support-knls-avx512-instruction-set/diff]. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2068> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

[Einstein Toolkit] #2074: Correct error in vertex-centred prolongation operators
by Einstein Toolkit 06 Nov '17

06 Nov '17

#2074: Correct error in vertex-centred prolongation operators ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: | ----------------------+----------------------------------------------------- See <https://bitbucket.org/eschnett/carpet/pull-requests/19/correct-error- in-vertex-centred/diff>. This corrects #2068. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2074> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #2023: CarpetInterp hangs with openmpi
by Einstein Toolkit 28 Oct '17

28 Oct '17

#2023: CarpetInterp hangs with openmpi -----------------------------+---------------------------------------------- Reporter: anonymous | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: OpenMPI, Carpet | -----------------------------+---------------------------------------------- On three occasions with two different simulations (TOV, BNS) the code hung. In two cases, I could attach a debugger to the running process, and in both cases the backtrace looked like this: {{{ #0 0x00007f4ecfd5729a in __GI___pthread_mutex_lock (mutex=0xc40d730) at ../nptl/pthread_mutex_lock.c:79 #1 0x00007f4ec7224807 in ?? () from /usr/lib/openmpi/lib/openmpi/mca_btl_openib.so #2 0x00007f4ecdae734a in opal_progress () from /usr/lib/libmpi.so.1 #3 0x00007f4ecda2d3b4 in ompi_request_default_wait_all () from /usr/lib/libmpi.so.1 #4 0x00007f4ec61cb7b7 in ompi_coll_tuned_sendrecv_actual () from /usr/lib/openmpi/lib/openmpi/mca_coll_tuned.so #5 0x00007f4ec61d0df6 in ompi_coll_tuned_alltoallv_intra_pairwise () from /usr/lib/openmpi/lib/openmpi/mca_coll_tuned.so #6 0x00007f4ecda3a00f in PMPI_Alltoallv () from /usr/lib/libmpi.so.1 #7 0x00000000015458fe in CarpetInterp::Carpet_DriverInterpolate (cctkGH_=<optimized out>, N_dims=<optimized out>, local_interp_handle=3, param_table_handle=6421, coord_system_handle=0, N_interp_points=224, interp_coords_type_code=130, coords_list=<optimized out>, N_input_arrays=6, input_array_variable_indices=0x7fff38fbf640, N_output_arrays=24, output_array_type_codes=0x7fff38fbf660, output_arrays=0x7fff38fbfb00) at /home/wolfgang.kastaun/ET/Payne/Cactus/arrangements/Carpet/CarpetInterp/src/interp.cc:645 #8 0x000000000071ee4f in SymBase_SymmetryInterpolateFaces (cctkGH_=0xccb1be0, N_dims=<optimized out>, local_interp_handle=3, param_table_handle=6421, coord_system_handle=0, N_interp_points=224, interp_coords_type=130, interp_coords=0x7fff38fbe1a0, N_input_arrays=6, input_array_indices=0x7fff38fbf640, N_output_arrays=24, output_array_types=0x7fff38fbf660, output_arrays=0x7fff38fbfb00, faces=0) at /home/wolfgang.kastaun/ET/Payne/Cactus/arrangements/CactusBase/SymBase/src/Interpolation.c:381 }}} I'm not sure if this is a problem with Carpet or with my OpenMPI installation. It only happens rarely, after one day or so. I'm using ET version Payne, gcc 4.9.2, openmpi 1.6.5 on an infiniband interconnect. The code was compiled with OpenMP support and run using 4 threads per process. Looking at various variables in Carpet_DriverInterpolate with the debugger, I noticed that the vector tmp was reported with size -488221088, but this could also be mis-reported by gdb since the code was compiled with -O3. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2023> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

← Newer
1
...
4
5
6
7
8
9
10
11
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2017