Trac December 2015

trac@lists.einsteintoolkit.org

1 participants
96 discussions

[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] #1689: Cactus should exit with a nonzero exit code if an error occurs
by Einstein Toolkit 27 Apr '16

27 Apr '16

#1689: Cactus should exit with a nonzero exit code if an error occurs --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- In WarnLevel.c, in CCTK_VWarn (called by CCTK_Warn), it says if (level <= error_level) { CCTK_Abort (NULL, 0); } The second argument to CCTK_Abort is the exit code of the process. So if there is an "error" warning, the process exits with 0 exit code; i.e. success! This happens in several places in this file. The user guide does not say anything about the exit code of Cactus. I think that if Cactus has a level-0 warning, i.e. an error, then it should exit with a non-zero exit code, and Erik agrees. See http://lists.einsteintoolkit.org/pipermail/users/2014-November/003878.html -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1689> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1837: LocalInterp2 symmetry test fails on intel compiler machine
by Einstein Toolkit 19 Apr '16

19 Apr '16

#1837: LocalInterp2 symmetry test fails on intel compiler machine -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: LocalInterp2 | -----------------------------------+---------------------------------------- The intel compiler by default aggressively optimizes expressions, which causes failures in the delicate cancellations required for LocalInterp2's symmetry test. The attached patch changes compiler options for the affected file only. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1837> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #702: Tests should use IO::out_fileinfo = "none"
by Einstein Toolkit 18 Apr '16

18 Apr '16

#702: Tests should use IO::out_fileinfo = "none" -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- The Cactus User Guide (http://einsteintoolkit.org/documentation/UsersGuide/UsersGuidech9.html#x13-…) recommends that test output files should always be the same, and hence use IO::out_fileinfo = "none". I would like to implement this for the tests in the ET, as it makes comparing test output using standard (non-Cactus testsuite mechanism) diff tools possible. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/702> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #1631: The dgfe branch for McLachlan generates NaNs
by Einstein Toolkit 17 Apr '16

17 Apr '16

#1631: The dgfe branch for McLachlan generates NaNs -----------------------------------------------------------+---------------- Reporter: Jonah Miller <jonah.maxwell.miller@…> | Owner: eschnett Type: defect | Status: new Priority: optional | Milestone: ET_2014_11 Component: EinsteinToolkit thorn | Version: development version Keywords: dgfe,mclachlan,gamma driver | -----------------------------------------------------------+---------------- When one uses the gamma driver formulation in the dgfe branch of McLachlan and sets the shiftGammaCoefficient to zero, the runtime output has NaNs because the code divides by zero. A bit of flow control fixes this. Attached is a patch for the branch. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1631> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #1646: McLachlan does not give a reference for the gauge evolution equations
by Einstein Toolkit 11 Apr '16

11 Apr '16

#1646: McLachlan does not give a reference for the gauge evolution equations -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: McLachlan | -----------------------------------+---------------------------------------- McLachlan_BSSN.m does not seem to contain any information (eg in evolCalc) that would tell me from which paper the different expressions for the shift and lapse evolution expression are taken from (which may be useful to understand what the different coefficients mean, since parsing the multiple factors of the type XXXFactor * AAA + (1-XXXFactor) * BBB to get either AAA or BBB is confusing). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1646> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1838: CactusUtils/WatchDog: is part of ET or not?
by Einstein Toolkit 01 Apr '16

01 Apr '16

#1838: CactusUtils/WatchDog: is part of ET or not? -----------------------------------+---------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: WatchDog | -----------------------------------+---------------------------------------- if yes, then: {{{ https://bitbucket.org/einsteintoolkit/manifest/pull-requests/6/add- cactusutils-watchdog-to-the-thornlist/diff }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1838> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1840: ExternalLibraris/pthreads does not provide CCTK_PTHREADS define
by Einstein Toolkit 01 Apr '16

01 Apr '16

#1840: ExternalLibraris/pthreads does not provide CCTK_PTHREADS define -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: rhaas Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: pthreads | -----------------------------------+---------------------------------------- This means it is not a drop in replacement for the old mechanism and eg HTTPD complains at runtime with: {{{ WARNING level 1 from host comet-ln3.sdsc.edu process 0 while executing schedule bin HTTP_Startup, routine HTTPD::HTTP_StartServer in thorn HTTPD, file /home/rhaas/cactus/ET_trunk/arrangements/CactusConnect/HTTPD/src/Startup.c:97: -> Parameter 'HTTPD::use_pthreads' is set to "yes" but you didn't configure with PTHREADS. Setting will be ignored. }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1840> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #1676: Add CT_MultiLevel elliptic solver to the Einstein Toolkit
by Einstein Toolkit 08 Feb '16

08 Feb '16

#1676: Add CT_MultiLevel elliptic solver to the Einstein Toolkit -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- This elliptic solver (http://lists.einsteintoolkit.org/pipermail/users/2013-August/003174.html) is being used by more people now, and it would be good to have it in the toolkit. It has tests and documentation, and the author supports (though has not requested) inclusion (http://lists.einsteintoolkit.org/pipermail/users/2014-January/003425.html). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1676> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1847: FFTW3 fortran interface not working for system installation
by Einstein Toolkit 25 Jan '16

25 Jan '16

#1847: FFTW3 fortran interface not working for system installation ----------------------+----------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- The FFTW3 thorn is able to detect system installations, but does not add (for example) /usr/include as include path since it is a standard system include path (for C), and could collide with other libraries. This is correct. However, some system fftw3 libraries install the fftw3.f Fortran file also in /usr/include, and expect this to be in the include path for the Fortran compiler. This, however, is not the case for all compilers (since /usr/include is meant for C headers, not Fortran), i.e., for gfortran. This could be seen as bug in the fftw3 installation, but we should provide a workaround. Right now, the FFTW3 thorn does not always provide a working interface for Fortran. Other libraries have similar problems, so I wonder if we could provide a common workaround. We have to add these directories as -I flag to the Fortran compiler, but we must not add it to the C or C++ compilers. I don't see a good way to currently do this within Cactus. Am I right? If so: would it make sense to have Cactus look for a variable, i.e., FFTW3_FINC_DIRS, and to only add those for Fortran compilations? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1847> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac December 2015