Trac March 2016

trac@lists.einsteintoolkit.org

1 participants
101 discussions

[Einstein Toolkit] #960: Dissipation thorn schedules LOCAL routines after GLOBAL ones
by Einstein Toolkit 27 May '16

27 May '16

#960: Dissipation thorn schedules LOCAL routines after GLOBAL ones ----------------------------------------------+----------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: Dissipation and SphericalSurface | ----------------------------------------------+----------------------------- Dissipation currently contains a schedule item {{{ SCHEDULE setup_epsdis AT cctk_poststep after SphericalSurface_HasBeenSet { LANG: C SYNC: epsdisA_group } "Setup spatially varying dissipation" }}} However SphericalSurface_HasBeenSet is AFTER SphericalSurface_Set which is a GLOBAL routine. Since GLOBAL routines run last in POSTSTEP (which is in EVOL) the AFTER modifier is ignored for all but the last (finest) refinement level. This can lead to the wrong surface shape to be used by the local routines. It might actually make sense to teach the flesh about GLOBAL/LOCAL etc and refuse AFTER/BEFORE statements that span different modes. This of course depends on how much work this is and if we expect the dependency and task based scheduler to be finished soon and if there are legitimate uses for AFTER/BEFORE to span modes. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/960> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1851: HDF5 won't configure on Fedora
by Einstein Toolkit 27 May '16

27 May '16

#1851: HDF5 won't configure on Fedora ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | ---------------------+------------------------------------------------------ The problem is that there's no way to tell it the correct place to look for H5pubconf.h (which is /usr/include/mpich-x86_64). There is an HDF5_INC_DIRS variable, but it's not exposed through configuration.ccl. Even if it's added, it gets overwritten by set_make_vars. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1851> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 22

[Einstein Toolkit] #912: Use CACTUS_CONFIGS_DIR in Formaline
by Einstein Toolkit 23 May '16

23 May '16

#912: Use CACTUS_CONFIGS_DIR in Formaline -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Formaline assumes that configurations are stored in a "configs" subdirectory of $CCTK_HOME. Use $CACTUS_CONFIGS_DIR instead. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/912> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1595: Is {{{*)}}} allowed as upper boundary for a parameter range?
by Einstein Toolkit 19 May '16

19 May '16

#1595: Is {{{*)}}} allowed as upper boundary for a parameter range? ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- I sometimes see these warnings when Cactus starts: {{{ WARNING[L1,P0] (Cactus): Invalid end of real-valued parameter range; range descriptor is "(0.0 : *)" (value is 1) }}} Presumably the warning depends on which thorns are active. This warning looks as if the syntax {{{*)}}} was accepted by the CST when parsing a param.ccl file, but was later not recognized by the flesh when checking a parameter value against this range. (The flesh uses HUGE_VAL as fallback, which happens to be correct in this case.) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1595> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 40

[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] #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] #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] #1864: Cactus build fails on file systems that do not update timestamps all the time
by Einstein Toolkit 22 Apr '16

22 Apr '16

#1864: Cactus build fails on file systems that do not update timestamps all the time --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- Ian and I recently ran into an issue caused by a particular file system (NFS v4 and also BeeGFS) not updating the file modification time when doing this: {{{ : >make.checked }}} which is what the build system uses (since [https://bitbucket.org/cactuscode/cactus/commits/0779c17697d3b4a254065c10836… 0779c17697d3b4a254065c10836770e355071f41] "Cactus: Replace "echo" by ":" in makefile" Thu Nov 27 16:35:13 2014 -0500) to update the marker files once a directory is finished building. While such a behaviour is not POSIX compliant (https://bugzilla.kernel.org/show_bug.cgi?id=6127), we'd still want to work around it. The simplest solution seems to me to revert [https://bitbucket.org/cactuscode/cactus/commits/0779c17697d3b4a254065c10836… 0779c17697d3b4a254065c10836770e355071f41] and use {{{ echo "" >make.checked }}} again. Erik: since you made the change, would you see any downside to reverting it? While investigating this Ian also found that some file systems only offer 1 second granularity in their timestamps (eg ext3 but also possibly XFS and NFS) which can negatively affect make if a rule takes less than a second to complete. See https://savannah.gnu.org/bugs/?40056#comment0 and https://www.gnu.org/software/autoconf/manual/autoconf-2.61/html_node /Timestamps-and-Make.html . The most conservative approach would be to (arrange for) {{{sleep 1}}} to execute after each make recipe. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1864> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac March 2016