Trac November 2013

trac@lists.einsteintoolkit.org

1 participants
148 discussions

[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] #1484: close file handles in CarpetHDF5 reader when VisIt closes files
by Einstein Toolkit 12 Feb '14

12 Feb '14

#1484: close file handles in CarpetHDF5 reader when VisIt closes files ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: development version Keywords: CarpetHDF5 | ------------------------+--------------------------------------------------- The VisIt plugin contains some caching logic for the HDF5 file metadata (namely which datasets exist in which file, can be disabled by setting the environment variable CARPETHDF5_CACHE_METADATA to "no"). There is a design flaw in this code that causes it to never close the HDF5 file handle which in turn causes libHDF5 to use up memory and (importantly) to not free the OS file handle. With large runs and many variables it is quite possible to run out of file descriptors. The attached patch tries to correct this by freeing the HDF5 handle when VisIt closes a file (but keeps the cached metadata in memory). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1484> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1459: ExternalLibraries/PAPI does not build with gcc 4.8.1
by Einstein Toolkit 12 Feb '14

12 Feb '14

#1459: ExternalLibraries/PAPI does not build with gcc 4.8.1 -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: PAPI | -----------------------------------+---------------------------------------- not sure if this depends on the gcc version, but I get the following error when trying to compile PAPI: {{{ PAPI: Building... pfmlib_common.c: In function 'pfmlib_parse_event_attr': pfmlib_common.c:760:10: error: declaration of 'endptr' shadows a previous local [-Werror=shadow] char *endptr = NULL; ^ pfmlib_common.c:737:20: error: shadowed declaration is here [-Werror=shadow] char *s, *p, *q, *endptr; ^ cc1: all warnings being treated as errors }}} I attache the full output of make. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1459> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #1435: count evolved variables automatically in Refluxing
by Einstein Toolkit 12 Feb '14

12 Feb '14

#1435: count evolved variables automatically in Refluxing -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: Refluxing | -----------------------------------+---------------------------------------- the attached patch reliefs the user from some variable counting (there is still some) when using Refluxing and will automatically find out which variables are evolved with MoL and which use a non-MoL time integration scheme. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1435> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1438: do not require --thornlist for build --reconfig
by Einstein Toolkit 12 Feb '14

12 Feb '14

#1438: do not require --thornlist for build --reconfig -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- The attached patch removes the requirement to provide a new thornlist when doing a sim build --reconfig . Since the typical reason (at least this is the only case I encountered this) for this is that the Cactus config changed (and the Cactus build system wants a make sim-reconfig) one usually does not want to change the thornlist at all. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1438> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1465: Boost doesn't honor parallel build options
by Einstein Toolkit 12 Feb '14

12 Feb '14

#1465: Boost doesn't honor parallel build options -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- ExternalLibraries/Boost doesn't honor parallel build options. This is because it doesn't use 'make' to build, but a tool called 'b2', which isn't using 'make's environment variables, nor is it capable to interact with the jobserver make provides. Manually parsing MAKEFLAGS inside the configure script of the thorn also doesn't work, as this doesn't contain the requested number of jobs, but only the fact that a parallel build was requested and a pointer to the jobserver. Manually interacting with this job server might be possible for gnu make, but is probably messy and highly likely not portable. However, building a huge package like Boost in parallel is something we have to achieve. On my workstation it reduces the time used for building Boost alone from about 500s to 60s. The only alternative that is easy enough to implement that I can see right now is to make it possible to pass a number of processes used for building to Cactus (in addition to passing it to make), and Boost using this variable for the parallel build. Simfactory should then also pass this to Cactus. One downside of this would be that if multiple libraries were to be built in parallel you might end up using almost twice as many jobs than specified. On the other hand, this doesn't seem to be the case right now and even if using twice as many might be better than many times too few. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1465> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1314: increase number of triggers in AEIThorns trigger
by Einstein Toolkit 11 Feb '14

11 Feb '14

#1314: increase number of triggers in AEIThorns trigger -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: Trigger | -----------------------------------+---------------------------------------- currently the max is 10. I find myself needing more (15 to be precise). Can we increase this number to say 39 (or some other largish non-typical number) or are that many parameters too expensive to support? Similarly (but more complicated) it would be useful to be able to steer more than one parameter/grid scalar when a trigger triggers. The current way of specifying targets is unfortunately not well suited for this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1314> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1117: Wrong CarpetIOASCII headers for complex 2D output.
by Einstein Toolkit 25 Jan '14

25 Jan '14

#1117: Wrong CarpetIOASCII headers for complex 2D output. ----------------------------------------+----------------------------------- Reporter: reisswig@… | Type: defect Status: new | Priority: minor Milestone: | Component: Other Version: | Keywords: ----------------------------------------+----------------------------------- I am outputting a 2d _complex_ array (called "extracted_vars") using 2d CarpetIOASCII output. Using the standard output format, the data starts at column 13. So the first array element "extracted_vars[0]" is at column 13. Now, since I have a complex array, the second element, "extracted_vars[1]", must be at column 15 (column 14 contains the imaginary part of element [0]). In older versions of Carpet, this was reported correctly in the header. In the current version, it is incorrect. The second element, "extracted_vars[1]" is reported to be in column 14 instead of 15. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1117> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #542: Remove thorn CactusArchive/ADM from thorn list
by Einstein Toolkit 25 Jan '14

25 Jan '14

#542: Remove thorn CactusArchive/ADM from thorn list -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: task | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Remove thorn CactusArchive/ADM from thorn list. This thorn is outdated, and we should updated out test cases instead. It also takes a long time and a lot of memory to compile. If we want an ADM formulation (which is doubtful since we don't use it ourselves), we should implement one via Kranc. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/542> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #114: per-variable tolerances for Cactus testsuites
by Einstein Toolkit 24 Jan '14

24 Jan '14

#114: per-variable tolerances for Cactus testsuites -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: major | Milestone: ET_2011_06 Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- It would be nice to be able to specify per-variable testsuite tolerances in Cactus (per regexp for the name in the ideal case). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/114> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 24

← Newer
1
...
8
9
10
11
12
13
14
15
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac November 2013