Trac November 2012

trac@lists.einsteintoolkit.org

1 participants
156 discussions

[Einstein Toolkit] #1148: New thorn CactusTest/TestCrayPointers
by Einstein Toolkit 08 Mar '13

08 Mar '13

#1148: New thorn CactusTest/TestCrayPointers -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- I want to add a thorn CactusTest/TestCrayPointers that tests whether the Cray pointer syntax is accepted by the Fortran compiler. If so, please create the respective repository. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1148> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1139: Adding PeriodicCarpet to the Einstein Toolkit
by Einstein Toolkit 26 Feb '13

26 Feb '13

#1139: Adding PeriodicCarpet to the Einstein Toolkit -------------------------+-------------------------------------------------- Reporter: bentivegna | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | -------------------------+-------------------------------------------------- Old thorn Periodic does not behave correctly with AMR patches that overlap the periodic boundaries (see ticket #694). A significantly different mechanism to handle has been implemented, by Erik, in LSUThorns/PeriodicCarpet. This thorn should be added to the Einstein Toolkit, and slowly replace Periodic. Before introducing this thorn to the ET, we need at least one testcase with AMR. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1139> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1186: Provide a version of CCTK_WARN which never returns
by Einstein Toolkit 25 Feb '13

25 Feb '13

#1186: Provide a version of CCTK_WARN which never returns -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- CCTK_WARN(0,...) always causes a fatal abort, but the compiler does not know this. Hence, it incorrectly warns that variables might be used without being set because it doesn't know that the only path that doesn't set them terminates the program. I propose introducing a new function CCTK_WARN_ABORT(...) which calls CCTK_WARN(0,...) and is declared with the attribute noreturn (http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Function- Attributes.html) so that the compiler knows that it can never return, and does not make incorrect conclusions when computing variable dependencies (CCTK_Abort is already defined without an error message). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1186> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #1017: Changes to options don't re-run configure scripts in external libraries
by Einstein Toolkit 20 Feb '13

20 Feb '13

#1017: Changes to options don't re-run configure scripts in external libraries ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1017> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1116: changing library options in optionlist does'nt trigger rebuild of depending thorns
by Einstein Toolkit 20 Feb '13

20 Feb '13

#1116: changing library options in optionlist does'nt trigger rebuild of depending thorns --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- I first built Cactus using OpenMPI shipped with the thorn MPI. Then I changed the optionlist to point to a local mpich2 installation and tried to rebuild Cactus using the new optionlist (sim build --thornlist=./thornlists/einsteintoolkit.th --optionlist=numrel-gcc.cfg). The new options are used in config-info and on the link line, however, thorns depending on MPI are not rebuilt, leading to link-failures because these thorns have been built against OpenMPI. Any change in the configuration of external libraries should lead to a rebuilt of depending thorns. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1116> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #950: "Correct" Weyl Scalar symmetries
by Einstein Toolkit 19 Feb '13

19 Feb '13

#950: "Correct" Weyl Scalar symmetries ---------------------------------+------------------------------------------ Reporter: yosef@… | Type: defect Status: new | Priority: major Milestone: | Component: Other Version: | Keywords: ---------------------------------+------------------------------------------ RotatingSymmetry180 and the ReflectionSymmetry thorns define a tensor alias "weylscalars_real", but the symmetries given there do not correspond to those of the usual re[psi0], im[psi0], re[psi1], im[psi1], etc scalars. The Weyl symmetries as provided in RotatingSymmetry180 static int const weylparities[10][3] = {{+1,+1,+1}, {-1,-1,-1}, {+1,+1,+1}, {-1,-1,-1}, {+1,+1,+1}, {-1,-1,-1}, {+1,+1,+1}, {-1,-1,-1}, {+1,+1,+1}, {-1,-1,-1}}; The symmetries for rpsi0, ipsi0, rpsi1, ipsi1, ..., rpsi4, ipsi4 static int const weylparities[10][3] = {{+1,+1,+1}, /* rpsi0 */ {-1,-1,-1}, /* ipsi0 */ {+1,+1,-1}, /* rpsi1 */ {-1,-1,+1}, /* ipsi1 */ {+1,+1,+1}, /* rpsi2 */ {-1,-1,-1}, /* ipsi2 */ {+1,+1,-1}, /* rpsi3 */ {-1,-1,+1}, /* ipsi3 */ {+1,+1,+1}, /* rpsi4 */ {-1,-1,-1}}; /* ipsi4 */ attached is a diff between the current ET version of the Reflection and RotatingSymmetry180 thorns and the "corrected" version. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/950> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #737: simfactory sync can lead to inconsistent builds
by Einstein Toolkit 11 Feb '13

11 Feb '13

#737: simfactory sync can lead to inconsistent builds ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- simfactory's sync command uses rsync with the --archive (-a) option. This option set the modification date of files on the target machine to that on the source machine. This can lead to inconsistent builds in the following situation: [1] local: edit source_file.c [2] local: simfactory sync [3] local: edit source_file.c [4] remote: simfactory build [5] local: simfactory sync [6] remote: simfactory build [6] will not rebuild source_file.o since [5] set the modification time to that of [3] which which is older than [4] hence make will not consider source_file.o to be out-of-date. A simple fix is to add --no-times to the rsync options. Unfortunately this disables rsync's file modification time optimization and requires it to compute checksums on all files which can be very slow on slow filesystems. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/737> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1161: Add thorn libwebp
by Einstein Toolkit 08 Feb '13

08 Feb '13

#1161: Add thorn libwebp -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Webp is an image format that is superior to png, and may supercede it at some point. We should have an external library to support it. See <https://code.google.com/p/webp/>. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1161> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1070: EOS_Omni::poly_gamma_ini should default to poly_gamma
by Einstein Toolkit 08 Feb '13

08 Feb '13

#1070: EOS_Omni::poly_gamma_ini should default to poly_gamma -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- At the moment, EOS_Omni::poly_gamma and EOS_Omni::poly_gamma_ini are two parameters for the adiabatic exponent, one used only for initial data, the other for evolutions. Both default to 2.0. This means that if someone, unaware of poly_gamma_ini, changes only poly_gamma the result is usually catastrophic (wrong results or c2p failures). I myself didn't notice today and had to debug my way down to find my mistake. I propose to make the default of EOS_Omni::poly_gamma_ini to be whatever EOS_Omni::poly_gamma is. One way to achieve that would be to use some special value for EOS_Omni::poly_gamma_ini which would usually not being used to indicate that behavior and to make that default. However, this being an exponent, at least in theory, all real values are allowed. Another approach would be to introduce a new boolean parameter which would allow users to use an initial value for gamma which is different from the one of the initial data. This would be 'saver', but has the drawback of a new parameter. Nevertheless, I favor the second approach. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1070> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 18

[Einstein Toolkit] #1099: CarpetLib::interpolate_from_buffer_zones should by default set to "no"
by Einstein Toolkit 08 Feb '13

08 Feb '13

#1099: CarpetLib::interpolate_from_buffer_zones should by default set to "no" --------------------+------------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: ET_2012_11 Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- CarpetLib::interpolate_from_buffer_zones should by default set to "no" after it is properly tested and we should think about whether we have a good reason to not remove that paramter then again. Adding the release tag because we don't want to have a change like this affecting two releases. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1099> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac November 2012