Trac May 2016

trac@lists.einsteintoolkit.org

1 participants
117 discussions

[Einstein Toolkit] #1842: clang-format options not valid for versions <=3.5
by Einstein Toolkit 08 May '16

08 May '16

#1842: clang-format options not valid for versions <=3.5 --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- The current .clang-format file is not valid for clang-format versions 3.5 and below. The attached patch would 'fix' this by removing key words not known in version 3.5, but still wouldn't work for versions below that. I do not suggest to apply the patch - it should just show that this is quite some number. Looking at the .clang-format file it seems that it does not use one of the pre-defined styles, but rather creates it's own (even if it is based on one given the comment in the file). I wonder if all of this is really necessary, or if we could not simply use one of the pre-defined styles, possibly with a few changes that work across clang-format versions. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1842> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1883: InterpToArray test failing after CarpetInterp2 vectorisation optimisation
by Einstein Toolkit 07 May '16

07 May '16

#1883: InterpToArray test failing after CarpetInterp2 vectorisation optimisation --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: ET_2016_05 Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- With the merging of [[https://bitbucket.org/eschnett/carpet/pull- requests/12/carpetinterp2-vectorize-interpolation| carpetinterp2 -vectorize-interpolation]], the test [[https://build.barrywardell.net/job/EinsteinToolkit/750/testReport/junit/(ro…]] is now failing with, for example, {{{ arrays2d[0].x.asc: substantial differences significant differences on 3 (out of 3) lines maximum absolute difference in column 5 is 0.255929043803272 maximum relative difference in column 5 is 0.659886735180889 }}} This is on the build machine, which uses GCC. I only tested the change on Intel. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1883> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1886: Browse source in trac website refers to svn code
by Einstein Toolkit 07 May '16

07 May '16

#1886: Browse source in trac website refers to svn code ----------------------------+----------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: optional | Milestone: Component: Cactus website | Version: development version Keywords: Trac | ----------------------------+----------------------------------------------- the links behind the Browse source toolbar button: https://trac.einsteintoolkit.org/browser refers to code in subversion. It should instead point to the various git repos on bitbucket or be removed. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1886> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #584: Use of uninitialized value in concatenation
by Einstein Toolkit 07 May '16

07 May '16

#584: Use of uninitialized value in concatenation ------------------------+--------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- After failing to check out a thornlist (the current einsteintoolkit.th) the automated build and test system re-runs GetComponents with --update. On 27-Sep-2011, this gave the error: {{{ Use of uninitialized value in concatenation (.) or string at ./GetComponents line 2514. }}} This line seems to be {{{ $url = "(".$component{"URL"}.")|(".$component{"AUTH_URL"}.")"; }}} Is the problem that SimFactory doesn't have an AUTH_URL? I'm attaching the log of the testsuite script. I don't know if the error is serious or not, since the checkout has already failed. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/584> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1812: GetComponents needs to come with (a selected few) trusted certificates
by Einstein Toolkit 07 May '16

07 May '16

#1812: GetComponents needs to come with (a selected few) trusted certificates ---------------------------+------------------------------------------------ Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ Most encrypted connections use some form of certificates. We use both ssl for subversion and git. The problem with certificates is that the certificate of the root CA has to be trusted by a client to be able to form a trusted connection. Otherwise users get warnings, and either cannot connect at all, or have to manually approve. We don't want both happening with GetComponents. Root CA certificates have to be changed from time to time. They have a limited life time. In addition, there is a big movement away from SHA-1 certificates right now, as this has been found weak. The problem with that is that an updated root CA might not have it made to all (or at least most) clients at the time a user might have to trust it. Usually, root CAs are created, but not actually used for some time for that reason. Security problems like SHA-1 interfere with that. All this is nothing we can change. So, in the light of root CAs possibly faster changing than clients update (and especially supercomputers update slowly in particular), we have to have a mechanism to make GetComponents still work 'out of the box' with these - no matter what the protocol is that actually uses it. Right now, we only seem to have problems with svn, but in the future we might have the same problem with git (bitbuckets root CA is still using SHA-1). For Subversion I propose the following. We ship 'too new' certificates with GetComponents (in-source, to still have one file). We then write this to a temporary file during checkout, and use the following option to svn to get it to accept it: {{{ --config-option servers:global:ssl-authority-files=<FILE> }}} This mechanism was tested manually on one of the problematic machines (stampede), with one of the problematic certs (InCommon). This only works for svn version 1.6 and newer. Most installations should have that. In case we encounter an older one we could disable trusted cert checking for problematic cases using --trust-server-cert. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1812> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1882: mpirun hangs on fedora 23
by Einstein Toolkit 07 May '16

07 May '16

#1882: mpirun hangs on fedora 23 ---------------------------------+------------------------------------------ Reporter: msahrling@… | Owner: Mikael Sahrling Type: defect | Status: new Priority: blocker | Milestone: Component: SimFactory | Version: development version Keywords: | ---------------------------------+------------------------------------------ Running sim/mpirun -np 2-10 ./cactus_sim BBH* hangs on Fedora 23 after some time, 1min - 1hr. I have disabled the firewall since that caused mpirun to hang for others but it still hangs for me. It could be related to the usb interface since sometimes touching the keyboard/mouse during sim causes the system to hang. I'm running on a single linux box with 64GB RAM. Anyone seen anything like this? Thanks, -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1882> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1877: TimerReport change requires C++11, but Cactus does not
by Einstein Toolkit 02 May '16

02 May '16

#1877: TimerReport change requires C++11, but Cactus does not --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- The commit https://bitbucket.org/cactuscode/cactusutils/commits/5c812eb236f4ff033fc1c2… uses C++11 features which are not enabled by Cactus autoconf. Erik warned in the ET call yesterday that this might be a problem. The error you get is Checking status of thorn TimerReport In file included from /usr/include/c++/4.8/array:35:0, from /home/jenkins/workspace/KrancTutorial/Cactus/arrangements/CactusUtils/TimerReport/src/Output.cc:16: /usr/include/c++/4.8/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options. #error This file requires compiler and library support for the This is when compiling without an optionlist on Ubuntu 14.04. * If we want to require C++11 for Cactus, then we should configure for it (i.e. add the -std=gnu++11 option when configuring, as is done in several simfactory optionlists). * My feeling is that C++11 compiler support might not be diffuse enough or mature enough to require for Cactus, which prides itself on portability, but I'm not up-to-date on the current C++ landscape. The above error message, on a version of Ubuntu which has been LTS up to a week ago, suggests that the GCC authors were also not sufficiently confident in the implementation. The [[https://gcc.gnu.org/projects/cxx- status.html#cxx11|GCC C++11 page]] doesn't seem to list recent GCC versions, but the latest version listed (4.8) still describes the support as "experimental". * Maybe the C++11 features being used in TimerReport are not critical, and can be easily worked around? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1877> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac May 2016