Trac April 2013

trac@lists.einsteintoolkit.org

1 participants
178 discussions

[Einstein Toolkit] #1337: CarpetHDF5 doesn't support complex datatypes
by Einstein Toolkit 25 Apr '13

25 Apr '13

#1337: CarpetHDF5 doesn't support complex datatypes -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- The visit CarpetHDF5 reader doesn't support complex grid functions. Visit itself probably doesn't have support for complex numbers, but the reader could at least import the real and imaginary part. A bonus would be if it could, on the fly, also provide the phase and absolute value. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1337> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1174: decrease warning messages from compilation of ET
by Einstein Toolkit 25 Apr '13

25 Apr '13

#1174: decrease warning messages from compilation of ET -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: ET_2013_05 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1174> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1156: Outdated thornlists under McLachlan/doc
by Einstein Toolkit 25 Apr '13

25 Apr '13

#1156: Outdated thornlists under McLachlan/doc -----------------------------------+---------------------------------------- Reporter: bentivegna | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- The two thornlists under McLachlan/doc still reflect pre-ET thorn locations. Update or remove? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1156> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1336: Permission to execute rsync on supermuc.
by Einstein Toolkit 25 Apr '13

25 Apr '13

#1336: Permission to execute rsync on supermuc. ------------------------+--------------------------------------------------- Reporter: bentivegna | Owner: eschnett Type: defect | Status: new Priority: blocker | Milestone: ET_2013_05 Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- The user home directory containing the rsync default in supermuc.ini: /home/hpc/pr32pi/lu78kog2/rsync-3.0.9/bin/rsync is not world accessible. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1336> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1294: Don't use STRICT_ANSI on stampede
by Einstein Toolkit 25 Apr '13

25 Apr '13

#1294: Don't use STRICT_ANSI on stampede ------------------------+--------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: ET_2013_05 Component: SimFactory | Version: ET_2012_11 Keywords: backport | ------------------------+--------------------------------------------------- The attached patch undefines U__STRICT_ANSI__ on stampede, similar to other machines. One effect of this is that M_PI is defined when math.h is included. By default, the lib otherwise follows the strict standard that math.h is not to pollute the namespace and doesn't define M_PI because it is not in the ANSI standard (but e.g. in POSIX). The ET depends on M_PI being defined in several thorns and a discussion on this topic took place on the mailing list some time ago. The consensus there was to try to make sure with compiler flags that POSIX is available, and with that M_PI. I committed this change to /trunk of simfactory already (in r2008), but want to have a positive review for a backport to Ørsted. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1294> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1335: SimFactory should abort if there are no checkpoint files when submitting an existing configuration
by Einstein Toolkit 24 Apr '13

24 Apr '13

#1335: SimFactory should abort if there are no checkpoint files when submitting an existing configuration -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- When submitting a simulation which already contains at least one restart, simfactory should abort if there are no checkpoint files available. This likely means that something went wrong. Starting the simulation again is always the wrong thing to do in this case, as it will waste CPU time and might go unnoticed. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1335> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1329: GetComponents is not asking for svn password
by Einstein Toolkit 23 Apr '13

23 Apr '13

#1329: GetComponents is not asking for svn password ---------------------------+------------------------------------------------ Reporter: knarf | Owner: eric9 Type: defect | Status: new Priority: minor | Milestone: ET_2013_05 Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ GetComponents uses the --non-interactive option to svn even for an initial checkout, which, even if needed, doesn't ask for an svn password. The effect is that if svn passwords are not already stored, a checkout using -noa fails on every repository that has to use passwords. That means that we probably have to remove the --non-interactive option from svn checkout commands. GetComponents has to let svn handle this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1329> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1332: Prolongation operators are only parallelized in one direction
by Einstein Toolkit 22 Apr '13

22 Apr '13

#1332: Prolongation operators are only parallelized in one direction -------------------------+-------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | -------------------------+-------------------------------------------------- Currently, Carpet's prolongation operators are only parallelized in one direction (the largest). This happens before calling the actual operator in call_operator() (CarpetLib). With increasing core(thread)-counts this is a problem. There are hardly enough points in any single direction to make this efficient. Wouldn't it be much better (in terms of openmp efficiency) to let the operators handle openmp-parallelization themselves? I currently see quite a large overhead for real-world parfiles with 32 threads just because of this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1332> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1331: www.einsteintoolkit.org leads to apache test page
by Einstein Toolkit 22 Apr '13

22 Apr '13

#1331: www.einsteintoolkit.org leads to apache test page -------------------------------------+-------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- entering http://www.einsteintoolkit.org instead of http://einsteintoolkit.org brings me to the apache test page. Since this might be a common mistake, we might want to put a redirection page at the incorrect page. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1331> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1330: hwloc might build against cuda, in which case Cactus needs to link against it
by Einstein Toolkit 21 Apr '13

21 Apr '13

#1330: hwloc might build against cuda, in which case Cactus needs to link against it -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2013_05 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- Currently, the hwloc pkg-config does not work in some cases, and the 'reasonable guess' in configure.sh doesn't as well. The main problem seems to be that pkg-config is called before PKG_CONFIG_PATH is set. The attached patch fixes this and allows me to build on a system where cuda libraries are installed (and the hwloc autoconf finds them and links against them), but Cactus isn't configured for cuda. Without the patch linking Cactus fails because of missing cuda libraries. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1330> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac April 2013