Trac June 2017

trac@lists.einsteintoolkit.org

1 participants
96 discussions

[Einstein Toolkit] #984: SimFactory should store the optionlist used when building in the simulation directory
by Einstein Toolkit 31 Jul '17

31 Jul '17

#984: SimFactory should store the optionlist used when building in the simulation directory ------------------------+--------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- SimFactory should store the optionlist used in the simulation directory -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/984> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1638: Automated build and test environment should be updated to Ubuntu 14.04
by Einstein Toolkit 17 Jul '17

17 Jul '17

#1638: Automated build and test environment should be updated to Ubuntu 14.04 -------------------------+-------------------------------------------------- Reporter: hinder | Owner: hinder Type: enhancement | Status: new Priority: minor | Milestone: ET_2014_11 Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- The automated build and test environment used by the ET (see https://build.barrywardell.net) is currently running Ubuntu 12.04, the previous stable release. The new 14.04 stable release is now available, and we should test on that instead. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1638> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #2001: Output bare masses of punctures to TwoPunctures.bbh metadata file
by Einstein Toolkit 13 Jul '17

13 Jul '17

#2001: Output bare masses of punctures to TwoPunctures.bbh metadata file -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- The pull request https://bitbucket.org/einsteintoolkit/einsteininitialdata /pull-requests/1/twopunctures-output-bare-masses-in/diff adds support to TwoPunctures for outputting the bare masses of the punctures to the TwoPunctures.bbh metadata file. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2001> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #2045: remove pirahe cache files in make clean
by Einstein Toolkit 03 Jul '17

03 Jul '17

#2045: remove pirahe cache files in make clean --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- Right now no clean target seems to remove them. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2045> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 17

[Einstein Toolkit] #2049: ExternalLibraries/MPI leads to link error in some cases
by Einstein Toolkit 30 Jun '17

30 Jun '17

#2049: ExternalLibraries/MPI leads to link error in some cases -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: critical | Milestone: ET_2017_05 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- The MPI thorn does not properly set the list of libraries necessary to link against it when built. In particular, when built on a Debian stable (stretch) system, the 'rt' and 'util' libraries are pulled in by MPI, but not set in MPI_LIBS, leading to a Cactus link error in the end. Adding 'rt' and 'util' in general might not be the best idea, as this is very likely system-specific (to Linux in this case). What needs to be done is to use information about the built library _after_ it was built to set MPI_LIBS, as we cannot (always) predict which libraries MPI will pull in. This is complicated by the fact that those variables are set in detect.sh, and not build.sh, so build.sh would need means to set/change those variables. But since this is executed in a parallel make session usually, this requires some care. Note that in case a pre-existing library is used, 'rt' and 'util' are correctly added to the required libs, because detect.sh actually queries the library. It cannot do that when building, because by that time it isn't built yet, and by the time it is, it is too late to tell Cactus at the moment. I'll file this as a bug for the MPI thorn for now, but a better handling in Cactus in general is needed here. Also setting this as critical for the release, because it breaks the build on a major Linux distribution. One might be tempted to temporarily "fix" this by adding 'rt' and 'util' to LIBS in debian.cfg. That is a bad idea, however, because Debian isn't a Linux-only distribution, and in general one might not even want to use OpenMPI there. The same is true for adding 'rt' and 'util' to MPI_LIBS in build.sh, because that would only work on a system that has this library installed. On a Linux system, however, this solves the linking problem. Ideally, we find some at least partial solution within only the MPI thorn for the current release, down-grade priority and assign to Cactus itself for a general solution. This has come up with other libraries in the past if I remember correctly. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2049> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #2019: Several tests fail in Jenkins after move to new NCSA build node
by Einstein Toolkit 29 Jun '17

29 Jun '17

#2019: Several tests fail in Jenkins after move to new NCSA build node -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- After the move of the Jenkins build system from UCD to NCSA, several tests started failing. See https://build- test.barrywardell.net/job/EinsteinToolkit/936/testReport/ for the details. The thorns with failures are CT_MultiLevel, SphericalHarmonicReconGen and GRHydro. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2019> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #2052: piraha assumes that assert(false) always aborts
by Einstein Toolkit 29 Jun '17

29 Jun '17

#2052: piraha assumes that assert(false) always aborts --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: piraha | --------------------+------------------------------------------------------- I recently tried compiling Cactus with the Cray compiler on BW and get (among other things) warnings like this: {{{ CC-940 crayc++: WARNING File = src/piraha/Piraha.hpp, Line = 326 A "return" statement is missing from the end of a non-void function "cctki_piraha::LookAhead::match". bool match(Matcher *m) { assert(false); }//TODO: Fill in }}} which is indeed a bug. If one defines NDEBUG (as is done for the highly optimized option lists) then assert() is a no-op and the function (if it was called) returned garbage. I see three solutions: 1. call CCTK_Abort() 1. add a "return false;" or so 1. remove the whole function definition. I think C++ does not mind if declared member functions of a class are not defined, just so long as they are never actually called. This would have the advantage of generating a compile time error as well rather than a run-time error. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2052> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #2051: CST stage always regenerates all files
by Einstein Toolkit 27 Jun '17

27 Jun '17

#2051: CST stage always regenerates all files ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- I notice that since recently, the Cactus CST stage always regenerates all files, which means that any change to a ccl file or the thorn list will recompile all source files, which is very slow. I find that this patch resolves the problem: {{{ $ git diff CSTUtils.pl diff --git a/lib/sbin/CSTUtils.pl b/lib/sbin/CSTUtils.pl index 532f6a77..209b9352 100644 --- a/lib/sbin/CSTUtils.pl +++ b/lib/sbin/CSTUtils.pl @@ -182,8 +182,8 @@ sub WriteFile if (-e $filename) { # only read the file if it its size equals the length of the rdata string - my @fileinfo = stat ($filename); - if ($fileinfo[7] == length ($$rdata)) + my $filesize = -s $filename; + if ($filesize == length ($$rdata)) { open(IN, "< $filename"); $data_in = join ('', <IN>); }}} Apparently, something fishy is happening when calling {{{stat}}}. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2051> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #2039: Meudon_Bin_NS update
by Einstein Toolkit 20 Jun '17

20 Jun '17

#2039: Meudon_Bin_NS update -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- The attached patch generalizes the Meudon_Bin_NS thorn: - to be able to use any value for 'gamma' (EoS) other than 2 - to be able to use an EoS provided by EOSOmni. In particular, this enables piecewise polytropes of any kind, as long as the initial data was generated using the same "table" ... along with a few minor changes: - check that the input file name exists - add a few more parameter descriptions - allow setting the derivatives of the gauge to zero while still taking the gauge from Lorene While a patch is attached, the new version could probably be tested the easiest from https://bitbucket.org/GravityPR/prthorns/src/master/Meudon_Bin_NS -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2039> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #583: PITTNullCode lacks test case outputs
by Einstein Toolkit 13 Jun '17

13 Jun '17

#583: PITTNullCode lacks test case outputs -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The PITTNullCode arrangement has several test parameter files without associated output. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/583> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

← 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 June 2017