Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1511: links in web-thornguide lead to incorrect thornguide
by Einstein Toolkit 14 Mar '14

14 Mar '14

#1511: links in web-thornguide lead to incorrect thornguide -------------------------------------+-------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: development version Keywords: thornguide | -------------------------------------+-------------------------------------- the online version of the thornguide seems to contain a correct table of content. Clicking eg on the CoreDoc link in http://einsteintoolkit.org/documentation/ThornGuide/ThornGuide.html brings me to http://einsteintoolkit.org/documentation/ThornGuide/ThornGuidech20.html#x26… which seems to be the documentation for EllSOR. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1511> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1556: Online Thorn Guide broken
by Einstein Toolkit 14 Mar '14

14 Mar '14

#1556: Online Thorn Guide broken ----------------------------------------+----------------------------------- Reporter: joachim.frieben@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: Keywords: broken index | ----------------------------------------+----------------------------------- Browsing the online documentation for the various thorns it turns out that the index at http://einsteintoolkit.org/documentation/ThornGuide/ThornGuide.html is broken for "Part F CactusElliptic" which points instead to "Part F CactusIO" and similarly for everything that follows. This makes the web page pretty much unusable .. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1556> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 30

[Einstein Toolkit] #1522: Improve determining make dependencies
by Einstein Toolkit 13 Mar '14

13 Mar '14

#1522: Improve determining make dependencies -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Cactus automatically determines the dependencies between source files and their include files. This mechanism doesn't quite work in all cases; e.g. when a source file (or header file?) is removed, the build aborts, and the auto-generated dependencies have to be deleted automatically. I have recently come across a mechanism that works reliably. Here is the relevant Makefile fragment, applied to building C++ files: {{{ # Taken from <http://mad-scientist.net/make/autodep.html> as written # by Paul D. Smith <psmith(a)gnu.org>, originally developed by Tom # Tromey <tromey(a)cygnus.com> PROCESS_DEPENDENCIES = \ sed -e 's/$@.tmp/$@/g' < $*.o.d > $*.d && \ sed -e 's/\#.*//' \ -e 's/^[^:]*: *//' \ -e 's/ *\\$$//' \ -e '/^$$/ d' \ -e 's/$$/ :/' < $*.o.d >> $*.d && \ rm -f $*.o.d %.o: %.cc ${CXX} -MD ${CPPFLAGS} ${CXXFLAGS} -o $@.tmp -c $*.cc @${PROCESS_DEPENDENCIES} @mv $@.tmp $@ -include ${DEPS} }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1522> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #1553: Prevent the user defining non-static functions in more than one object file
by Einstein Toolkit 11 Mar '14

11 Mar '14

#1553: Prevent the user defining non-static functions in more than one object file -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- If a non-static function is defined in more than one object file, the results at run-time are unexpected or unpredictable. I was under the impression that there were compiler options to prevent this. At least on Mac OS, these must not be used, as I just ran into this problem. So, either we find out which options are needed and add them, or we could provide some additional checks in the build system to help catch this error. For example, Cactus scheduled functions defined with the same name should be easy to catch. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1553> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1552: Support OS X 10.9.2
by Einstein Toolkit 25 Feb '14

25 Feb '14

#1552: Support OS X 10.9.2 ---------------------------+------------------------------------------------ Reporter: barry.wardell | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | ---------------------------+------------------------------------------------ The attached patch adds support for OS X 10.9.2 to the Cactus build system. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1552> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1545: Parameter file parser errors should be more informative
by Einstein Toolkit 20 Feb '14

20 Feb '14

#1545: Parameter file parser errors should be more informative --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- The following error message produced by the parameter file parser does not tell me which parameter was being set; the information is there because of the line number, but it is odd to have an error message which doesn't output the content of the line with the error. {{{ WARNING level 0 in thorn ML_BSSN processor 0 host shelob001 (line 158 of bench.par): ->Invalid assignment: Attempting to set a variable of type KEYWORD with (BOOL)false }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1545> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1543: hwloc in lib64
by Einstein Toolkit 13 Feb '14

13 Feb '14

#1543: hwloc in lib64 -----------------------------------+---------------------------------------- Reporter: barry.wardell | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- Often the hwloc libraries are installed in /usr/lib64. However, several places in the configure script assumes it is installed in $HWLOC_DIR/lib. I suggest applying the attached patch to correct this. Additionally, the script assumes $HWLOC_DIR/lib/libhwloc.la exists. This causes grep to print a confusing error if it does not exist. The second patch causes grep to only run if this file exists. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1543> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1533: checkpoint cctk_delta_time in PUGH
by Einstein Toolkit 13 Feb '14

13 Feb '14

#1533: checkpoint cctk_delta_time in PUGH -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: IOHDF5Util | -----------------------------------+---------------------------------------- the PUGH driver currently does not checkpoint the stepsize which makes using it with adaptive timestepping hard. Carpet on the other hand checkpoints the stepsize. The attached patch writes cckt_delta_time into checkpoints. When reading a checkpoint file that does not set the timestep, the user will see level 1 warning that the attribute cctk_delta_time was not found but the code will not abort and will behave as it does right now otherwise (which is to use cctk_delta_time based on the values from parameters/set in basegrid). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1533> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1444: CarpetLib does not compile with gcc 4.8 due to static_assert
by Einstein Toolkit 13 Feb '14

13 Feb '14

#1444: CarpetLib does not compile with gcc 4.8 due to static_assert --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- Attempting to compile CarpetLib with gcc 4.8 leads to the error /Users/ian/Cactus/arrangements/Carpet/CarpetLib/src/prolongate_3d_rf2.cc:501:56: error: 'static_assert' was not declared in this scope I had not come across static_assert before. Apparently it is a C++11 feature. gcc 4.6 was able to compile it, but it looks like gcc 4.8 is stricter. Do we want to require -std=c++11, or should we avoid C++11 features for now? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1444> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1538: Turn CCTK_REAL8 etc. into typedefs
by Einstein Toolkit 12 Feb '14

12 Feb '14

#1538: Turn CCTK_REAL8 etc. into typedefs -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Currently, CCTK_REAL8 are #defines. This is inconvenient, since e.g. CCTK_REAL16 may be "long double", and the C++ syntax {{{ CCTK_REAL16(x) }}} is then illegal, since this expands to "long double(x)". Turning CCTK_REAL8 and friends into proper typedefs remedies this. The attached patch also corrects two small issues in cctk_Types.h: (1) The include guard around "cctk_Config.h" should not be there, and (2) some #endifs have wrong comments. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1538> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac