Trac January 2014

trac@lists.einsteintoolkit.org

1 participants
145 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] #1509: ExternalLibraries do not check if patch is available
by Einstein Toolkit 12 Feb '14

12 Feb '14

#1509: ExternalLibraries do not check if patch is available --------------------------------------------+------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: LORENE hwloc ExternalLibraries | --------------------------------------------+------------------------------- some of the ExternalLibraries (LORENE, hwloc for example) use patch to modify the upstream source. However they do not check if patch is available and blindly use the flesh supplied $PATCH variable. Since the flesh does not abort its configuration even when patch is missing, this fails with an error message of the form "-p0: command not found". Either the flesh's configure should require patch to be present, or the ExternalLibraries need to test for PATCH being empty (there is a bash expansion that aborts if PATCH is undefined). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1509> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[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] #1521: Piraha smart_ptr can't handle self assignment
by Einstein Toolkit 12 Feb '14

12 Feb '14

#1521: Piraha smart_ptr can't handle self assignment ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- An assignment of the form {{{ void foo(smart_ptr<T> x) { x = x; } }}} will not work, since operator= assumes that LHS and RHS are different objects. The usual remedy is to add an if statement, doing nothing for self assignment. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1521> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[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] #1512: LoopControl slows down with time when exloring new tilings
by Einstein Toolkit 05 Feb '14

05 Feb '14

#1512: LoopControl slows down with time when exloring new tilings -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: LoopControl | -------------------------+-------------------------------------------------- the attached parfile does nothing but apply the periodic boundary condition over and over again. The run slows down with time, and spends more and more time in Slab's apply routine (Periodic just uses lots of calls to Slab). Digging further this caused by LoopControl and in particular setting {{{ LoopControl::settle_after_iteration = 0 }}} restores the expected behaviour, namely that the runtime in Pariodic/apply increases linearly with the number of timesteps rather than superlinearly. I blind guess for the culprit is the std::map inside of loopcontrol. I have done no further digging into the code though. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1512> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

← Newer
1
...
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 January 2014