Trac October 2012

trac@lists.einsteintoolkit.org

1 participants
189 discussions

[Einstein Toolkit] #591: Add harmonic shift to McLachlan
by Einstein Toolkit 15 Apr '13

15 Apr '13

#591: Add harmonic shift to McLachlan -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: McLachlan | -----------------------------------+---------------------------------------- The attached patch adds a harmonic shift condition to McLachlan. It does this by introducing a new real-valued parameter harmonicShift. This should be set to 0 for gamma-driver shift (the default, and the existing behaviour), and to 1 for harmonic shift. This is useful for code- correctness tests with the shifted gauge wave which is an exact solution of the Einstein equations in harmonic gauge. The harmonic shift equation has been tested with the shifted gauge wave exact solution and yields convergence to the exact solution. The current way that gauge conditions is handled in McLachlan is not very elegant, and I don't think this patch should be applied as-is. I am putting it here for anyone who might find it useful. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/591> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #624: Replace Cactus complex number implementation with C/C++ standard implementation
by Einstein Toolkit 08 Mar '13

08 Mar '13

#624: Replace Cactus complex number implementation with C/C++ standard implementation -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Cactus offers CCTK_COMPLEX. This maps to the standard datatype in Fortran, but not in C or C++. It should map to the standard datatypes in C and C++ as well, so that the growing body of code written in C and C++ can reasonably make use of complex numbers. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/624> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[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] #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] #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
...
7
8
9
10
11
12
13
...
19
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac October 2012