Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #2061: ML_BSSN claims to READ variables that it doesn't read
by Einstein Toolkit 03 Aug '17

03 Aug '17

#2061: ML_BSSN claims to READ variables that it doesn't read -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- McLachlan/ML_BSSN/schedule.ccl contains READS: ML_BSSN::Xt1(Everywhere) but McLachlan/ML_BSSN/src/ML_BSSN_ADMBaseEverywhere.cc does not contain any mention of this variable. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2061> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[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] #2057: ML_BSSN_bench8 does not compile due to non-existent group
by Einstein Toolkit 20 Jul '17

20 Jul '17

#2057: ML_BSSN_bench8 does not compile due to non-existent group -----------------------+---------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: optional | Milestone: Component: Other | Version: development version Keywords: McLachlan | -----------------------+---------------------------------------------------- Trying to compile ML_BSSN_bench8 I get (both 2017_06 and 2017_11 release): {{{ CST error 1: -> Schedule error: Thorn ML_BSSN_bench8_Helper - group ML_dtlapserhs doesn't exist. HINT: Check ML_dtlapserhs really is in thorn ML_BSSN_bench8_Helper. Groups from other thorns need to be specified using <implementation>::ML_dtlapserhs and <implementation> must be inherited by your thorn. CST error 2: -> Schedule error: Thorn ML_BSSN_bench8_Helper - group ML_dtshiftrhs doesn't exist. HINT: Check ML_dtshiftrhs really is in thorn ML_BSSN_bench8_Helper. Groups from other thorns need to be specified using <implementation>::ML_dtshiftrhs and <implementation> must be inherited by your thorn. }}} Note that ML_BSSN_bench8 is not part of the ET so the bug is not important. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2057> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #2056: sim setup does not override sourcebasedir for existing machines
by Einstein Toolkit 18 Jul '17

18 Jul '17

#2056: sim setup does not override sourcebasedir for existing machines ------------------------+--------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- If I set up simfactory in a nonstandard directory on a supported machine, sim setup only writes a {{{[default]}}} section, not a {{{[machine]}}} section in defs.local.ini. This means that the sourcebasedir I supply at the interactive prompt is not used on this machine, because it is taken from the existing machine definition, and the version in {{{[default]}}} is ignored. This led to the error {{{ Error: The current directory '/home/ianhin/projects/gw150914tutorial/Cactus' is not a subdirectory of the sourcebasedir '/home/ianhin/Cactus'. This error can also be caused if you call Simfactory from outside a Cactus directory, or if this Cactus directory is not a subdirectory of the sourcebasedir. Aborting Simfactory. }}} when submitting a simulation. sim setup should apply any overrides to {{{[machine]}}} sections in the case that the machine already exists. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2056> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac